W O R K S H O P B A S I S

Workshop Basis

Outubro/2011

Vitor Oliveira

2

Conteúdo e Acesso ao Documento:

As informações apresentadas neste documento foram geradas pela Firsteam através de análises efetuadas no ambiente.O conteúdo deste documento é considerado sigiloso, destina-se ao uso exclusivo da Lupo e deve ser utilizado internamente, para avaliação de seus termos, aprovação e acompanhamento do projeto.

3

SUMÁRIO

R/3 BASIS TECHNOLOGY..........................................................................................................4 . . STARTING AND STOPING R/3 – NT VERSION……………………………………………...19 STARTING AND STOPING R/3 – UNIX VERSION………………………………………..….22 CCMS CONFIGURATION……………………………………………………………………….24 BACKGROUND PROCESSING………………………………………………………………....27 SYSTEM MONITORING..............................................................................................................30 USERS AND AUTHORIZATION IN THE R/3 SYSTEM............................................................32 USERS AND AUTHORIZATION IN THE R/3 SYSTEM............................................................40 TRANSPORT MANAGEMENT....................................................................................................41 TRANSPORT MANAGEMENT....................................................................................................43 R/3 UPGRADES AND OCS PATCHES......................................................................................47 R/3 SPOOL AND PRINT................................................................................................................51 R/3 OUTPUT MANAGEMENT......................................................................................................54 DATABASE FUNDAMENTALS....................................................................................................57 BACKUP ESTRATEGY...................................................................................................................63 SCHEDULING, PERFORMING AND MONITORING BACKUPS………………………………66

SYSTEM KERNEL ........................................................................................................................7

INTERFACES................................................................................................................................13

R/3 GRAPHICAL USER INTERFACE.........................................................................................16

4

R/3 Basis Technology

Basis System and the System Environment

The Integration Model

Sistema R/3 é composto dos seguintes módulos:• Logística

• SD – Sales & Distribution• MM – Materials Management• PP – Production Planing• QM – Quality Management • PM – Plant Maintenance

• Human Resources• HR – Human Resources

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

• Industry and Cross-Application• WF – Workflow • IS – Industry Solutions (não vem no standard)

A camada Basis integra todos estes módulos. É a parte central do “diamante” do diagrama do R/3e as demais são os módulos funcionais. Estes módulos se interconectam e interagem para garantirque o sistema é todo integrado, tanto na parte de processos quanto em relação a base de dados.

Business Framework Architecture

O Business Framework Architecture (BFA) é a arquitetura estratégica do produto R/3. Ela trabalhacom business components que são os módulos funcionais (FI, CO, etc.) configuráveis para se adaptara cada empresa. Esta arquitetura fornece agilidade para se adaptar a um novo negócio, além da facilidade de se integrar com pacotes externos e fácil integração com a internet e intranet, permitindo desta forma uma fácil evolução sem a interrupção da operação do negócio da empresa. O princípioda arquitetura é que cada componente possui vida própria e sua complexidade esta restrita a elemesmo. Para o mundo externo somente os métodos de interfaceamento são visíveis e acessáveis,fato que garante a total conexão deste com os demais sem causar grandes impactos ou interferências

O Business Framework se mostra no R/3 como uma família de componentes separados porém

• Business Components: são os módulos funcionais (FI, CO, etc.) é são formalmenteconhecidos como componentes relativos ao negócio;

• Business Objects: Ordem, Empregado, Material, etc. São o próximo nível de hierarquia doR/3. Pertencem a um Business component e podem ser considerados como objetos básicosdo sistema;

• BAPI Interfaces: São os métodos com que os objetos de negócio são implementados dentrodo R/3 (criar uma ordem, alterar o endereço de um empregado, etc.) e eventualmente podemter mais de uma versão para o mesmo interfaceamento.

A forma básica de distribuir as informações é o ALE e este será detalhado mais a frente.

5

R/3 as an Open System

O R/3 utiliza protocolos standard da industria para garantir a integração com outras aplicações: • TCP/IP: é o protocolo de comunicação difundido mundialmente; • EDI: Electronic Data Interchange, é o mecanismo utilizado para trocar informações de negócio

com diferentes sistemas; muito utilizado pelos bancos;• OLE: Object Linking and Embendding, integra aplicações PC com o R/3 (padrão microsoft);• Open Interfaces, tais como arquivamento ótico, dispositivos de códigos de barras, etc.

Além de standard da indústria, o R/3 também utiliza• RFC: Remote Function Call, que utiliza o protocolo copiado do CPI-C da IBM para

comunicação e processamento das aplicações e tasks dentro do sistema R/3 ou com osistema R/2 ou outros sistemas;

• ALE: Application Link Enabling permite o processamento distribuído dentro do R/3. Na práticaestá associado a distribuição de informações a partir de um modelo de divulgaçãopreestabelecido;

Scalability and the Client/Server Concept

O R/3 possui uma arquitetura modular de software seguindo o princípio da arquiteturacliente/servidor com enfoque na distribuição da força de processamento entre as várias plataformasenvolvidas.

Esta arquitetura permite que se separe a lógica da aplicação da base de dados e da camada deapresentação. Esta configuração permite ainda otimizar os custos e distribuir a carga através de configurações variadas de hardware. Com isto é possível dimensionar os servidores de acordo com acarga, permitindo a fácil escalabilidade do ambiente.

Os ganhos nesta arquitetura na implementação R/3 são muitos: • Simples instalação de novos servidores para eliminar eventuais gargalos de processamento;• Servidores trabalham em paralelo, com carga homogênea e execução local dos programas; • Baixo tráfego de rede com a localização dos buffers de dados e programas próximo de onde

• Balanceamento de carga, seja para o processamento online (logon) seja para oprocessamento batch.

Ou seja, o ponto alto da arquitetura é a facilidade para escalar e aumentar o poder deprocessamento

Client/Serve Principles

Na implementação R/3, a arquitetura client/server é orientada para o software, e não para ohardware como estamos acostumados a ver. Desta forma, Client é quem requisita e utiliza o serviço e

Um servidor de aplicação por exemplo é server de alguns serviços das estações clients, porém éclient dos serviços fornecidos pelo servidor de banco de dados. Ou seja, o conceito do papel de quemé o cliente e de quem é o servidor é o que prevalece não importando quem tem mais hardware ou quem normalmente executa a atividade.

R/3 System Client/Server Configurations

Os serviços (ou camadas) fundamentais de uma aplicação são três: Presentation, Application eDatabase services e existem várias formas de se implementar um sistema R/3, a saber :

6

• Central, onde todos os componentes estão implementados em um mesmo host. Estaimplementação corresponde a clássica implementação mainframe e não é comum de serimplementada;

• Two-tier, onde uma camada normalmente executa as funções de presentation (usualmenteum PC) e a outra camada executa os serviços de application e database. Uma outraimplementação two-tier poderia ser uma camada executando os serviços de database e aoutra composta por PCs mais potentes que executariam as funções de presentation eapplication. A primeira implementação é comum em ambientes pequenos e com poucadisponibilidade de hardware para os servidores. A última implementação é normalmente utilizada em simulações ou desenvolvimento de software.

• Three-tier, onde cada serviço tem o seu próprio host. Nesta configuração é possível aindaassegurar uma divisão de carga na camada de aplicação, garantindo que determinados hostsfiquem dedicados para aplicações específicas. Por exemplo dedicar um host para servidor de aplicação dos usuários de MM, ganhando com isto performance na distribuição dos serviços.

A configuração three-tier é a mais recomendada em R/3 por garantir a melhor distribuição decarga e escalabilidade nos grandes sistemas. Todos os servidores em uma configuração R/3 devem

Um sistema R/3 agrupa todos os componentes que estão associados com um banco de dados. Seutilizamos uma implementação em 3 camadas, os componentes do R/3 estarão presentes em todasas camadas da hierarquia:

• Database Server, é instalado em um host central, onde todos os serviços de bancos de dados

• Um ou mais Application Servers conectados ao servidos de banco de dados. Nestesservidores estarão sendo processados a lógica da aplicação, ou seja, os programas.

• Vários Presentation Servers conectados aos servidores de aplicação. Estas máquinas sãotambém chamadas de frontends ou workstations. Nestas máquinas os usuários irão interagircom o sistema R/3 utilizando uma interface que proverá os serviços de presentation.

The Middleware Basis

O software Basis do R/3 (também chamado de middleware) roda em diferentes plataformas e também pode ser adaptado para atender as necessidades individuais das empresas. São vários os

• Provê o ambiente de runtime para as aplicações R/3• Cuida da perfeita interação das aplicações com o sistema• Define uma arquitetura estável para as melhorias do sistema• Contém todas as ferramentas necessárias para a administração do ambiente • Permite a distribuição eqüitativa dos recursos e componentes do sistema• Provê as interfaces necessárias para os sistemas descentralizados e os produtos externos ao

R/3

As principais características da tecnologia Basis são:• É uma arquitetura voltada para a configuração client/server• Trabalha com bancos de dados relacionais • Possui interface gráfica com o usuário (GUI)

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

Portability and System Plataforms for the R/3 System

Para garantir uma alta portabilidade, as interfaces com o software básico são divididas em suas próprias camadas que variam de sistema para sistema (NT ou UNIX, Oracle ou Informix, etc.). Acimadestas camadas as funcionalidades dos componentes R/3 são basicamente as mesmas,independentemente do hardware, software ou sistema operacional.

7

System Kernel

R/3 Presentation Interface

A interface de apresentação do R/3 é o SAPGUI que apresenta uma funcionalidade muito parecida entre as diversas plataformas do R/3. Um usuário treinado em uma determinada plataforma, salvopequenas exceções está apto a operar o sistema nas suas mais diversas implementações. O fluxo deinformação entre o SAPGUI e o servidor de aplicação não consiste de telas preformatadas, mas simde strings lógicos contendo dados e caracteres de controle, o que faz com que o tráfego de dados semantenha na casa de 1 a 2K por tela (cada enter). Estes “strings” são na verdade um protocolo decomunicação que é sempre utilizado para conversar com o dispatcher e é chamado de DIAG(dynamic information and action gateway) O dispatcher é quem cuida da troca de dados, entre oapplication e o sapgui, e a ordem de processamento está na dispatche queue ou request queue. Aregra é sempre obedecer a FIFO (first in, first out).

R/3 Database Interface

O R/3 trabalha com bases de dados relacionais, que são compostas de tabelas bidimensionais einteragem com os sistemas através da linguagem padronizada SQL (Structured Query Language) que é comum a todas as implementações de bases relacionais, embora cada fabricante implementealgumas extensões no seu produto.

O DB Interface é um módulo dentro do R/3 que converte os comandos SQL codificados nosprogramas ABAP para o SQL nativo do banco implementado em cada ambiente R/3. Ou seja, cadaimplementação (Oracle, Informix, SQL Server) possui um módulo de DB Interface particular paraaquela implementação, o que torna os programas ABAP independentes da implementação do banco.

Estes comandos SQL escritos no ABAP são denominados OPEN SQL e o DB Interface é responsável pela sua correta transcrição para o SQL nativo do banco. Além disso, um programaABAP pode codificar o comando diretamente em Native SQL. Neste caso o comando não passará pelo DB Interface, indo diretamente para a DB machine. Estes comandos poderão não serindependentes do banco utilizado, se utilizarem extensões particulares de um determinado RDBMS.

Os comandos SQL escritos em OPEN SQL tem sua sintaxe verificada pelo DB Interface queinicialmente faz um acesso no buffer interno do application server para evitar acessos desnecessários ao DB server. Comandos escritos em native SQL não fazem uso deste buffer interno, uma vez que o

Normalmente as tabelas que vemos no R/3 são armazenadas no DB. Estas tabelas sãoconhecidas com tabelas transparentes. Elas são implementadas no DB exatamente como vemos nodicionário do R/3. Existem outros tipos de tabelas que são declaradas no dicionários mas não sãoimplementadas exatamente como aparecem. As tabelas do tipo Pool são declaradas no banco comouma só mas para o R/3, aparentemente, são tabelas como outras quaisquer. Este recurso é utilizadopara tabelas de poucas ocorrências e para evitar um grande número de tabelas. Existem também astabelas tipo Cluster. Essas são uma desnormalização do dado dentro do modelo relacional. Maisprecisamente é como se tivéssemos o conceito de campos múltiplos dentro de um registro (queinfringe a primeira regra normal).

O DB Interface não é o processo que acessa e mantém a conexão com o banco. Este processo éconhecido como shadow process e roda na máquina onde está o banco de dados fazendo a ligaçãodo db interface, que está na maquina onde está a instance, e o banco de dados.

8

Work Processes and Dispatcher

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

Os work processes são serviços dentro de um sistema R/3 especializados em determinadastarefas.

O centro de um sistema R/3, a nível de controle de aplicação, é o Dispatcher. Ele, juntamente como sistema operacional, é o responsável pelo controle e disponibilização dos recursos do sistema.Suas principais tarefas são o controle da comunicação, a conexão com o presentation e a distribuiçãode carga entre os work processes. O dispatcher distribui os serviços requisitados entre os WPdisponíveis e se encarrega de enviar o dado processado para o SAPGUI, que deverá interpretá-lo eexibir para o usuário. Não existe um WP fixo para um determinado usuário, cuidando o dispatcher de ir utilizando-os conforme as requisições vão chegando, em um processo de fila FIFO.

Quando um sistema R/3 é inicializado, o dispatcher é o responsável por lêr os parâmetros de configuração (profiles), gerar as rol areas, inicializar os work processes e se conectar com o messageserver da central instance.

Cada dialog work process é coordenado por um componente interno denominado Task Handler.Ele ativa o screen processor ou o ABAP processor e é ainda o responsável pelo roll in e roll out dasáreas de usuário. Existem memórias de uso exclusivo de um determinado work process e memóriasque podem ser compartilhadas por todos eles. Esta diferenciação é gerenciada pelo memorymanagement. A memória utilizada exclusivamente por um work process possui duas áreasreservadas para dados específicos de uma determinada sessão de usuário (user context area) edevem ser mantidas entre as pseudo conversas do dialog. Estas áreas são denominadas roll e paging areas. A roll area contém dados que ficam imediatamente disponível para o processamento noinício do dialog step (roll in) e é salva novamente no final do dialog step (roll out).

Este mecanismo de roll in e roll out é que permite o share dos work process permitindo o compartilhamento do recurso entre todos os usuários. Nesta área são salvos os dados referentes aousuário (user context) tais como suas autorizações, informações administrativas além de dados adicionais para o ABAP e dialog processors, que são dados que já foram coletados por dialog stepsanteriores.Na shared memory existem dados disponíveis para todos os work processes, tais como ocalendar, screen, table e program buffers.

R/3 Application Services

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

Uma central instance possui ainda serviços de enqueue (que também é um work process) paragerenciamento de lock e dois outros serviços próprios:

• Message Server responsável pelo serviço de comunicação entre os vários dispatchers que compõem um sistema R/3, que é portanto um pré requisito para a escalabilidade de vários servidores de aplicação trabalhando em paralelo. Ele é muito usado para a troca de dados decontrole.

• Gateway Server, também chamado de CPI-C handler, que permite a comunicação entre R/3,R/2 e aplicativos externos. É muito utilizado para trocar dados da camada da aplicação,incluindo ai dados da mesma instância.

Resumindo, uma instância é nomeada pelos serviços que ela presta. Um bom exemplo disto é ainstância DVEBMGS00 que possui dialog, update, enqueue, batch, message, gateway e spool etodos respondendo pelo system number 00 que significa que a porta 3200 ser utilizada pelo sapdp00

9

(dispatcher), a 3300 será utilizada pelo sapgw00 (gateway) e a 3600 será utilizada pelo sapmsXXX (message).

Rules for the Type and Number of Processes in the Application

Service R/3, System-wide For each R/3 Instance Dialog >= 2 >= 2 Update >= 1 >= 0Enqueue 1 0 ou 1Background >= 2 >= 0Message 1 0 ou 1Gateway >= 1 1 Spool >= 1 >= 0

R/3 Transaction and LUW

Transações são unidades de processamento agrupadas em funções que executam alteraçõesconsistentes na base de dados, de acordo com a funcionalidade a que se propõem. Um exemplotípico seria o débito em uma conta para crédito em outra, que somente fazem sentido consistentequando executadas como um todo.

Uma transação SAP é implementada através de uma série de dialog steps consistentes econectados de forma coerente. Uma transação SAP não executa necessariamente em um único workprocess, uma vez que cada um dos seus dialog steps poderão estar sendo atendidos por WPdiferentes que o dispatcher encontrou disponível em cada momento. Além disso, quando se utiliza o asynchronous update para processar as atualizações da base de dados, estes processos estarãosendo atendidos por outros work process que poderão inclusive se encontrar em outros hosts.

No R/3 cada dialog step é composto de um processamento que inicia após o usuário entrar o dado (PAI – Process After Input) e pelo processamento e envio da próxima tela (PBO – Process BeforeOutput). Do ponto de vista do usuário, cada dialog step começa com o preenchimento de uma tela e oposterior processamento até o envio da próxima tela. Para o sistema apenas as partes referentes aoprocessamento (PAI e PBO) compõem o dialog step já que durante o preenchimento da tela nenhum

Este conceito de transação, que pode compor de um ou vários dialog steps, é chamado de LUW,ou Logical Unit od Work. Como os bancos de dados não suportam o conceito de transação paratodos os processos conversacionais (begin/end transaction commands), é necessário saberdiferenciar uma transação do ponto de vista SAP (SAP-LUW) de uma transação de banco de dados(DB-LUW) que é totalmente executada ou totalmente desfeita. Não existe meio termo numa DB-LUW.Enquanto uma SAP-LUW garante a integridade lógica do banco de dados (um determinadolançamento deverá existir nas tabelas x, y e z), uma DB-LUW garante a integridade física do DB e éexecutado necessariamente pelo gerenciador do banco. Uma transação SAP inicia uma SAP-LUWque somente termina ao encontrar um comando COMMIT WORK no programa ABAP ou então nofinal do asynchronous update.

Lock Concept and Asynchronous Update

A técnica principal utilizada numa SAP-LUW é a atualização assíncrona, onde as requisições de update na base de dados são coletadas separadamente e iniciam após o COMMIT WORK, onde sãoexecutadas em uma única DB-LUW para garantir a integridade do banco.

Os mecanismos de lock existentes nos gerenciadores de bancos de dados não são suficientes para garantir a correta manipulação dos objetos de negócio, que muitas vezes envolvem uma série detabelas em um único lançamento. Com o seu próprio mecanismo, O R/3 assegura que determinados

10

dados permaneçam protegidos durante todo o processo de atualização do objeto. Esta tarefa éexecutada pelo Enqueue Work Process que utiliza uma tabela armazenada na memória principal (deonde o enqueue work process está rodando, também conhecido como enqueue server e énormalmente a central instance) para este gerenciamento.

Sempre que um lock é requisitado o sistema verifica (através do enqueue wp) se a requisição nãofere outro lock já postado na tabela. Havendo colisão de interesses, o processo é informado atravésde uma mensagem de erro, o que permite ao programa ABAP informar ao usuário que a suaoperação não poderá ser executada no momento. Caso o enqueue work process não se encontre namesma instance em que o processo está correndo, o que é normal em uma sistema R/3 de trescamadas, esta comunicação é efetuada pelo message server.

Para que este mecanismo de requisição de lock funcione no sistema R/3, é necessário que umobjeto de lock seja definido no dicionário ABAP especificamente para aquele objeto que se desejatravar. Já existem objetos definidos em uma tabela primária no dicionário do R/3, porém o usuáriopode definir seus próprios objetos em tabelas secundárias (estes objetos do usuário precisam ter

Os locks podem ser do tipo “S” (read) ou “E” (write). Um lock do tipo E somente poderá serpostado se não existe nenhum outro lock já definido sobre o registro. Quando um objeto de lock éativado, o sistema gera duas funcion modules, uma para ENQUEUE_<object> e outra paraDEQUEUE_<object>. Os lock postados por um programa permanecem até que sejam retirados pelopróprio programa ou ainda pelo procedimento de update (segunda parte da SAP-LUW).

Work processes podem gerar atualizações diretamente na base de dados mesmo que o banconão se encontre no mesmo host. Quando o programa ABAP utiliza os comandos CALL FUNCTION‘...’ IN UPDATE TASK, é criado no R/3 o mecanismo de asynchronous update. Neste caso arequisição é direcionada para uma tabela (a VBLOG) existente fisicamente no banco de dados queage como um buffer intermediário onde as requisições de atualização são enfileiradas.

Esta tabela contém basicamente o nome da rotina que será disparada para efetuar a atualização eos dados (parâmetros) para a rotina efetuar as atualizações necessárias. Transações que sãocanceladas pelo usuário não tem o seu registro de header completado na VBLOG e portanto suasatualizações não são efetuadas. Os registros de atualização podem ser divididos em componentes V1e V2. Basicamente processos que são críticos são armazenados em componentes V1 e processossecundários que são menos time-criticals são armazenados nos componentes V2. Informações de

O processo assíncrono de update é disparado pelo comando COMMIT WORK especificado noúltimo dialog step de uma SAP transaction. Nesta fase que ocorre na segunda parte da SAP-LUW, osregistros escritos na VBLOG são recuperados e atualizados fisicamente na base de dados. Casoocorram erros nesta fase em processos V1, as alterações no DB daquela DB-LUW são desfeitas porrollback e os registros permanecem na VBLOG assinalados com um flag de erro. Caso ocorram errosem processos V2, apenas aquele registro será setado com erro e as demais atualizações V2continuam sendo executadas.

Quando ocorrem os erros descritos acima, o usuário é notificado através de mail e medidascorretivas precisam ser avaliadas. Ao término da SAP-LUW, a task de update remove os lockspostados pelos dialog steps anteriores. Caso ocorram erros durante o update os locks também serãoremovidos.

Updates pendentes com erro podem ser restartados pelo administrador do sistema. A SAP nãorecomenda que updates V1 sejam restartados, devendo este procedimento somente ser efetuadopara updates dos tipo V2. Processos V1 deverão ser regerados processando novamente a transação (veja a nota 16083)

Quando um sistema R/3 sai, as entradas que estão com status INIT na VBLOG são processadastão logo o sistema retorne ao ar. Esta funcionalidade pode ser parametrizada pela profile do sistema.

Resumindo uma SAP-LUW, onde cada tópico é um dialog step :• usuário abre uma transação para atualizar uma determinada informação; Na prática o SAPGUI do

usuário entra em contato com o dispatcher da instância em questão e aciona o PAI da janelacorrente e providencia a exibição da janela desejada;

11

• usuário preenche os dados chave para a identificação da informação e o PAI é novamenteacionado. Neste momento o work process selecionado pelo dispatcher para tratar deste dialogstep localiza a informação desejada através do DB Interface e solicita ao Enqueue que arespectiva informação seja locada. Isto é feito pela função call function enqueue e pela inclusãoda lock table que fica na memória da onde esta sendo executado o enqueue.

• usuário, de posse da janela com os dados a serem atualizados, atualiza a informação e inicia umnovo dialog step. Este é o dialog step da nossa transação. Ele vai chamar a função call function inupdate task que incluirá as informações a serem atualizadas na tabela vblog. Para o dialog workprocess a atividade encerra quando o commit work é realizado. Mas na verdade para o R/3 oassunto ainda não está terminado pois o work process de update, a partir da tabela vblog, vaiprovidenciar que a atualização seja feita nas tabelas que possuem as informações reais e

call function dequeue. Esta parte da transação, que é feita peloupdate work process é conhecida como a segunda parte da SAP-LUW.

Background Processing

Processos que são schedulados para processamento pelos background work processes sãotratados no sistema da mesma forma que os processos online. Processos background sãoschedulados na forma de jobs. Cada job possui um ou mais steps (que podem ser external ou ABAPprograms) que são processados seqüêncialmente.

Através das classes de processamento (A, B ou C) é possível setar prioridades entre os jobs. Osjobs batch normalmente não são schedulados para processamento imediato, mas são especificadospara uma data/hora futura podendo ainda, quando necessário, serem definidos como periódicos.

O batch scheduler é o responsável pelo disparo automático dos jobs configurados no sistema.Este módulo é um programa ABAP que roda em um dialog work process por instância do sistemaR/3. Ele varre a tabela de scheduling e encontrar um job candidato o encaminha para processamento pelos background work processes. O sistema efetua balanceamento de carga para distribuir os jobsbatch entre os diversos servers que possuem work processes disponíveis (do tipo B). Jobs batchpodem ainda ser schedulados para processamento em servers específicos. Na escala de prioridade,para os jobs com mesmo horário de inicio, os Jobs classe A tem maior prioridade que os classe B epor último os jobs classe C. Dentro de um mesmo servidor e jobs schedulados com a mesma classe,tem prioridade aquele schedulado com especificação explícita de server (sem balanceamento). Apartir daí a ordem de inicialização é definida pela ordem de criação do job. Se for necessário saber aordem em que os jobs serão executados basta abrir a SM37, listar os jobs e classifica-los pela ordemcronologica. Se houver alguns jobs no mesmo horário devemos entrar em um a um para ver a data decriação e descobrir qual a ordem exata de execução.

Se for necessário bloquear a execução de jobs, basta setar o parâmetro rdisp/btctime = 0

R/3 Printer Services

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

R/3 Instance

Uma instância R/3 é uma unidade administrativa que combina componentes de um sistema R/3para prover um ou mais serviços. Todos os serviços providos por uma instância são iniciados (start dainstância) e parados (stop da instância) ao mesmo tempo. Uma instância é parametrizada através deparâmetros que descrevem todas as suas características.

12

Cada instância possui seus próprios buffers e um sistema R/3 central é composto de uma única instância que possui todos os serviços (DVEBMSGnn). O message server é o responsável pelacomunicação entre os application servers e um central message service para prover serviços deupdate trigger, enqueue e dequeue, background requests, e outras pequenas trocas de informações(normalmente dados de controle e pequenas quantidades de dados da camada de aplicação)

Cada dispatcher de um application server se comunica com um único message server em cadaambiente R/3, que portanto só é instalado uma única vez na central instance. É ele quem atribui qualwork process vai processar o dialog step que está iniciando. O controle desta fila é armazenada na dispatcher queue, também conhecida como request queue. Além dos dispatcher, os presentation(SAPGUI) poderão se logar nos application server através do message server para desta formaefetuar balancemento automático de carga (load balancing). O gateway é o responsável pela troca dedados (normalmente com bom volume de dados) entre as instâncias de um sistema R/3, entre sistemas R/3 e entre um sistema R/3 e outros sistemas

São as profiles que configuram as diversas instâncias e desta forma definem quem executa quaisserviços que estarão disponíveis. Por nomeclatura costumamos chamar os dialogs, background,enqueue, update e spool de work process e o gateway e message de serviços.

13

Interfaces

R/3 as an Open System

R/3 é um sistema aberto que permite a comunicação com várias outras plataformas, quer sejaentre as instâncias de um sistema R/3 ou com outros sistemas R/3, R/2 ou sistemas não SAP atravésde rede. A Comunicação em rede pode ser dividida em 7 camadas, onde cada camada serve deinterface entre a camada de baixo e camada de cima. Do ponto de vista da programação,desenvolver uma comunicação entre sistemas é mais fácil a medida que esta conversa éimplementada nas camadas mais superiores.

A SAP suporta os protocolos TCP/IP e SNA LU6.2. A comunicação entre sistemas R/3 se dá emTCP/IP e a comunicação LU6.2 é utilizada para a comunicação com sistemas R/2 baseados em mainframe. A programação R/3 suporta ainda CPI-C, RFC e OLE Automation como interfaces de comunicação. Os dois primeiros protocolos são proprietários da SAP e o OLE é um protocolo daMicrosoft para a comunicação entre aplicativos na plataforma windows

R/3 Gateway Service

SAP Gateway é o CPI-C handler, responsável pela conexão entre os protocolos TCP/IP e LU6.2,utilizado para a conexão entre sistemas R/3 e sistemas R/2 baseados em mainframe. O Gatewaypode rodar tanto em um application server quanto em um database server. Pequenas mensagens,como visto anteriormente, fluem entre os application e a central instance em um sistema R/3 através do message server. Já os volumes mais elevados de dados, tais como os dados da aplicação fluem

Com isto podemos ver que a comunicação através do gateway tanto pode se dar dentro de umsistema R/3 quanto entre um sistema R/3 e um sistema R/2 ou com programas externos. O gatewayutiliza o protocolo TCP/IP, através de RFC, para comunicação com os clients e LU6.2 apenas para a

Communication with CPI-C

CPI-C é um protocolo utilizado para a comunicação elementar program-to-program. É utilizadabasicamente para a comunicação entre sistemas R/2 e outros aplicativos mainframe. É aimplementação SAP da LU6.2. A comunicação faz uso dos verbos básicos da comunicação LU6.2(INIT, ALLOCATE, ACCEPT, SEND, RECEIVE e DEALLOCATE). Como no padrão IBM, é umprotocolo de comunicação que exige que enquanto um parceiro esteja transmitindo o outro seencontre em modo de escuta, e vice versa (sempre funciona na modalidade sincrona). Lembrar quese for o caso de estabelecer uma conexão com ambiente IBM será necessário usar funções feitas pela SAP para converter o conjunto de caracter de ascii para ebcdic.

Os parâmetros enviados pelo comando INIT são definidos através da tabela TXCOM e mantidos

Remote Function Call

RFC é uma interface de comunicação baseada em CPI-C mas que possui mais funções além deser mais simples de se utilizar. Pode ser utilizada para a comunicação entre sistemas R/3, R/3 com R/2 bem como aplicações externas. O RFC permite a chamada de subrotinas remotamente pela rede.Estas subrotinas são chamadas de function modules. Estas funções possuem parâmetros e retornamvalores como qualquer outra função e são gerenciadas dentro do R/3 através de sua própria functionlibrary, denominada Function Builder.

14

Function Builder (transação SE37) dá ao programador uma excelente ferramenta para programar,documentar e testar as function modules, que tanto podem ser chamadas em modo local quantoremotamente. O Sistema R/3 gera automaticamente todo o protocolo necessário para a comunicaçãoRFC entre os sistemas.

Os requerimentos para o RFC são os mesmos para o CPI-C. Os parâmetros para a comunicaçãoRFC são mantidos través da transação SM59. O R/3 vem ainda acompanhado de uma biblioteca defunções C para comunicação externa via RFC com o R/3, o RFC-SDK (Software DevelopmentSystem), sendo que o que diferencia uma chamada RFC local de uma remota é apenas o parâmetro(destination) que especifica onde o comando será executado

chamadas RFC : • Synchronous RFC call, onde o programa que emitiu a chamada suspende a execução até o

retorno da chamada• Asynchronous RFC call, onde a função chamada roda em paralelo e independente do

programa que emitiu o comando. O programador fica responsável pela conexão lógica dosresultados obtidos

• Transactional RFC call, onde várias funções são agrupadas em uma única transação que éexecutada no sistema remoto como uma única LUW na seqüência com que elas foramcodificadas. Caso ocorra um erro, o sistema que emitiu o comando recebe um código deretorno que pode ser consultado pela transação SM58. Ainda neste caso o sistema destinonão precisa estar disponível no momento em que o comando é emitido, podendo ainda serparametrizado o intervalo entre os queries.

Business Objects and BAPIs

Os business objects formam a base para a comunicação em alto nível no sistema R/3, tornandopossível por exemplo implementações R/3 na internet e tem as seguintes características:

• Formam a base para uma bem sucedida comunicação em sistemas client/servers• São orientados ao negócio. Existem BAPIs chamados Customer, Order, etc.• Possui métodos, que são os business functions que facilitam e padronizam a utilização destes

objetos• São gerenciados internamente pelo R/3 em uma biblioteca central, a Business Object

Repository, ou BOR

As BAPIs (Business Application Programming Interfaces) são interfaces funcionais que utilizambusiness methods para executar funções de negócio. Elas podem ser chamadas tanto pelosprogramas R/3 quanto encapsuladas e instânciadas por programas externos.

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

OLE (Object Linking and Embedding) é uma forma de comunicação entre programas orientadapara objeto. Com isto é possível conectar aplicações desktop que utilizam OLE2 (Word, Excell, etc.)com o sistema R/3. Quando o sistema R/3 está agindo como um client OLE, o usuário chama oprograma (word, excell) de dentro do programa ABAP. Os comandos OLE são transferidos para o PC

Os objetos OLE aos quais o R/3 pode se conectar como client são definidos internamente no R/3(através de type informations) onde se definem os métodos, atributos e parâmetros do objeto. A

(CREATE OBJECT, CALL METHOD, GET/SETPROPERTY e FREE OBJECT) que permitem instânciar e manipular o objeto. Quando o R/3 funcionacomo um OLE server, suas funções podem ser chamadas de dentro das aplicações que rodam nodesktop. Estas chamadas são enviadas ao SAP Automation Server que converte os calls para RFCs que são enviados ao sistema R/3. Estas chamadas ativam BAPIs ou function modules dentro dosistema R/3 que processam as informações que são então enviadas de volta para o AutomationServer que a repassa para o aplicativo no desktop.

Do ponto de vista da programação, usuários podem utilizar as function modules do R/3 em uma programação orientada para objeto, como por exemplo utilizando C++ ou Visual Basic. Isto é válido

15

para todos os objetos que são gerenciados centralizadamente pelo R/3 através da BOR (BusinessObject Repository). Como os BOR e function modules se encontram no R/3, para utiliza-los énecessário antes efetuar um logon, que pode ser feito de forma automatizada pelo programa.

Internet Architecture

ITS (Internet Transaction Server) forma o componente principal da arquitetura Internet da SAP. Ele é composto de dois componentes, o Application Gate (A Gate) e o Web Gate (W Gate). Do ponto devista do R/3, o A Gate age como um usuário comum, uma vez que o IST converte toda a conversacom o sistema para protocolos utilizados pelo SAPGUI. O A Gate mescla os dados recebidos comtemplates HTML e os envia através do W Gate para o HTTP server, onde são finalmente exibidospara o usuário através dos browsers padrão (explorer ou netscape).

A SAP fornece o IAC (Internet Application Component) que possui Web Transactions que nadamais são que mapeamentos Web de transações standard R/3. Assim como qualquer página HTML, ousuário pode customizar o lay out de acordo com suas necessidades. Para permitir uma boaperformance a SAP está rescrevendo algumas transações para que essas funcionem de formaintegrada com a internet.

EDI Architecture

Electronic Data Interchange é uma forma estruturada e eletrônica para trocar informações entrediversos sistemas. Esta arquitetura tem as seguintes características:

• EDI-enabled applications, que permite que transações de negócio sejam processadasautomaticamente

• A interface IDOC, que foi criada como uma interface aberta e consiste de documentosintermediários e seus respectivos function modules

• subsystem EDI, que converte os documentos intermediários em mensagens EDI e vice versa.O SAP não implementa esta facilidade

O componente principal desta interface é o Idoc, que é um SAP standard que especifica aestrutura e o formato do dado que está sendo transferido.

Distribution of Business Processes with ALE

Por razões técnicas ou de negócio pode ser necessário fazer uma implementação descentralizadado R/3. O conceito ALE (Application Link Enabling) permite configurar e operar aplicações distribuídasem SAP.

ALE consiste de uma troca controlada de mensagens de negócio, mais especificamente os dadosdo negócio, que permitem a integração consistente de sistemas distribuídos. Os aplicativos são integrados através de comunicações tanto síncronas quanto assíncronas e por TRFC (transactionalRFC). Para especificar um sistema distribuído é necessário especificar o modelo lógico dedistribuição de dados para definir em que sistema rodará e ainda entre quais e como os dadosdeverão ser intercambiados. Os dados também são transferidos através de Idocs (IntermediateDocuments) para possíveis aplicações de EDI.

Data Transfer and Batch Input

Quando se transfere dados entre sistemas R/3 ou entre o legado e o R/3, é importante garantirque estes dados entrem de forma consistente dentro do sistema destino. Desde que se utilize asmesmas transações conversacionais utilizadas pelos usuários para entrar com os dados no sistema,fica assegurado que os dados passarão pelas mesmas consistências que se efetuam nas entradas

O método comumente utilizado para entrada de dados do legado é conhecido como batch input.

16

R/3 Graphical User Interface

Frontend Administration

Usuários não necessitam da mesma configuração em seus PCs, embora umaworkstation simplifica o trabalho de administração. Considere a facilidade e a dificuldade paraatualizar os softwares da estação

Frontend Requirements: A nota 86895 descreve detalhadamente a configuração da estação

Item Configuração Mínima Configuração desejávelProcessador 486 Pentium 133 RAM 16MB 32MBNet connection Winsocket API Winsock.dll

Configuração para Windows NTItem Configuração Mínima Configuração desejávelProcessador Pentium 90 Pentium 133 RAM 32MB 48MBNet connection TCP/IP TCP/IP

Para testar o funcionamento da rede entre a estação e o host basta efetuar um ping ou telnet. As configurações no windows ficam nos arquivos host e services.

Para testar o funcionamento do SAPGUI utilize o comando sapgui <appserver> <nn> ou sapgui/H/appserver/S/32nn

SAPGUI Installation

Sempre que for instalar uma nova versão do SAPGUI é necessário deletar a versão anterior. Oprograma sappurge.exe pode ser utilizado para esta finalidade. A instalação é feita individualmenteem cada PC. Programe a melhor forma para otimizar o trabalho. O arquivo SAPSETUP.INI pode ser editado para parametrizar a instalação. Nele se configura quais os componentes a serem instalados e

O sapsetup.exe permite uma instalação dialog free startada a partir da linha de comando (veja oR/3 Installation Guide) o que assegura uma distribuição automática do software e a manutenção dofrontend utilizando logon scripts. A vantagem neste tipo de instalação é que a configuração dasestações é feita a partir de uma localização central através de um logon script, que faz todas as checagens necessárias (hardware e network) e executa as operações necessárias para instalar emanter o frontend. A desvantagem deste método é que se tem mais trabalho para implementar o check de versão no logon script e para analisar os resultados da instalação no arquivo sapsetup.log.A SAP recomenda que sob windows 95 e NT primeiro se faça uma instalação em um servidor(installation server) utilizando o installation wizard e posteriormente se instale os clients a partir dele.O programa utilizado na instalação é o \Gui\Windows\Win32\Sapsetup.exe

Types of Online Help

Existem diversos tipos de implementação do online help no R/3:• PlainHtmlHelp converte documentos para HTML standard. Pode ser instalado em todas as

plataformas de frontends e é exibida através dos browsers convencionais. Pode ser utilizadotanto com Windows 95, NT ou ainda quando um Web server é disponível na instalação(intranet)

• PlainHtmlFile converte documentos para HTML standard. Pode ser instalado em todas asplataformas de frontends e os documentos são acessados através de um file server que

17

disponibiliza os dados de um diretório por compartilhamento onde são exibidos através dosbrowsers convencionais nas estações. Pode ser utilizado tanto com Windows 95, NT ou aindaquando um Web server é disponível na instalação (intranet)

• HtmlHelpFile converte documentos armazenados no formato HTML comprimido para Htmlconvencional. Pode ser utilizado apenas em estações Windows 95 ou NT. É instalado em umfile server compartilhado, como o anterior, mas sua principal vantagem é que o espaçonecessário no file server é cerca de 90% menor, já que os arquivos se encontram compactados. O único pré requisito é que o browser já esteja instalado na estação antes dainstalação do SAPGUI, já que é o browser que contém todos os HTML controls necessários.

O tipo de help e sua localização são especificados como parâmetros nas profiles do R/3. Aconfiguração do arquivo SAPDOCCD.INI no frontend sobrepõe a definição genérica das profiles do R/3 e deve ser utilizada como complementação a definição do sistema central.

Os parâmetros importantes e relevantes para a configuração do help são o eu/iwb/help_type, oeu/iwb/installed_language e o eu/iwb/path_win32.

SAPLOGON – Options e traces

O programa saplogon.exe se encontra no diretório drive:\<target>\sapgui, conforme foi definido nomomento da instalação. O saplogon utiliza o programa sapgui.exe para se conectar com o applicationserver. O arquivo saplogon.ini configura as entradas disponíveis na janela do saplogon e é mantido quando se atualiza as entradas disponíveis do usuário. As informações lá contidas são utilizadas paramontar o string de conexão ao application server. Para evitar que o usuário edite as entradas deste

Ao se clicar no canto esquerdo da janela do saplogon é possível obter informações about quedescrevem a localização dos dois arquivos (sapgui.exe e saplogon.ini). O botão do canto superioresquerdo da janela permite ainda que se configure as opções de trace do saplogon e asfuncionalidades de edição. Estas definições ficam armazenadas na seção [Configuration] do saplogon.ini

Assim como o saplogon.ini, os arquivos sapmsg.ini e saproute.ini são mantidos implicitamentequando edita as entradas do saplogon. O primeiro contém a relação dos message servers e seus respectivos serviços (logical service names) que será lido sempre que se efetua uma requisição delogon a um logon group através do saplogon. O segundo arquivo (saproute.msg) lista os saproutersque podem ser selecionados no saplogon.

Já o arquivo services do windows não é editado pelo saplogon embora possua entradasfundamentais para o seu funcionamento, devendo portanto ser editado em separado. Nele sãoespecificadas entradas para os message servers definidos no sapmsg.ini, como por exemplo:sapms<SID> 36nn/tcp.

O saplogon utiliza o programa sapgui.exe para se conectar com o sistema R/3 e o string deconexão depende do target escolhido:

• Para conexão com uma instância R/3: sapgui /H/<appserver>/S/32nn• Para conexão com um message server: sapgui /M/<host name>/S/36nn/G/<logon group>• Para conexão saprouter: sapgui /H/<host1>/S/3299/H/<host2>/S/3299/H/<oss

host>/S/36nn/G/Public

Os números dos serviços poderão ser substituídos pelas respectivas entradas colocadas noservices: sapdp<nn> para o dispatcher e sapms<SID> para o message server. Só para constar, asportas do gateway (sapgw00) são as 3300.

Se for necessário, o log de start do sapgui pode ser ativado. Ele recebera o nome dev_9999.TDW(ascii) e dev_9999.log (binário) e serão gravados na area de work do sapgui. Eles possuem a log detudo que aconteceu.

Resumindo os arquivos ini. O saplogin.ini possui a configuração das instâncias e seus respectivossystem numbers. No sapmsg.ini teremos a indicação de quais são os messages de cada um dossistema R/3. No saproute.ini teremos as strings de roteamento do R/3 e no arquivo services teremos

18

as portas que serão utilizadas pelo dispatcher, gateway, message e etc. Devemos sempre tomarcuidado ao alterar o service pois ele não segue um padrão entre maquinas diferentes eprincipalmente com usos diferentes. Em relação a localização dos arquivos, os sap*.ini estão nodiretório do windows e o service ou está no diretório do win9x ou no system32/drivers/etc do winnt.

SAP MAPI and SAPGUI for java

O SAP MAPI permite a integração dos softwares de correio eletronico e o R/3. Especificamente oMAPI permite que o ambiente de troca de mensagens do R/3, conhecido como Office, passe a seracessado como se fosse uma pasta do Outlook ou do exchange da microsoft.

Uma outra evolução da SAP é a disponibilizarão do sapgui na linguagem java. Isto, pelo menos aprincípio, facilitaria a distribuição de softwares para as estações mas ainda possui o inconveniente doambiente ser mais complexo. Outra desvantagem é a tecnologia estar no inicio do vida e portantoainda sem contar com uma boa performance e estabilidade de ambiente. O arquivo quecorresponderia ao saplogon.ini neste ambiente é o IDES.html.

Durante a ativação de um sapgui java devemos lembrar que até o aparecimento da janela para o

• identificação do template (ides.html) que identifica o servidor a ser acessado;• carga das classes java que serão processadas no lado do cliente;• troca de mensagens entre os servidores para a montagem da página através do orbixd (object

requeste broker daemon).

Se for necessário saber mais sobre o assunto, procure pela nota 42268 ()

19

Starting and Stoping R/3 – NT Version

Operating System Tasks

Durante o startup do NT todos os serviços relacionados poderão ser inicializados automaticamente(desde que configurados através do control panel -> services). Em relação ao R/3 neste momento

SAP<SID>_<SystemNumber>, SAPOSCOL eOracleService<SID> devem ser inicializado. A seqüência de inicialização não é relevante pois um não depende do outro, mas para o start do R/3 todos já devem estar ativos.

O SAP<SID>_<SystemNumber> é o responsável por coordenar o start/stop do message e dogateway. O usuário utilizado para inicializar o serviço é o SAPService<SID> com a senha informada

O SAPOSCOL é o responsável por coletar as informações sobre os recursos do sistemaoperacional e suas respectivas cargas e disponibilizar estas informações para o R/3. O usuárioutilizado para inicialização também é o SAPService<SID>.

O OracleService<SID> é responsável pelo controle da instância oracle e não necessita de usuáriopara ser inicializado.

Administrator Tasks

Para inicializar o R/3 devemos sempre seguir a seguinte seqüência :• Os serviços básicos devem estar ativos (saposcol, sapSID_## e OracleServiceSAP)• Abrir a conta SIDadm na console do NT• Ativar a instância do Oracle (pode ser feito pelo instance manager da oracle)• Ativar a instância do R/3 (pode ser feito através do sap service manager)

O Sap Service Manager usa as cores para indicar a fase em que está cada serviço, a saber :verde (processo sendo executado), vermelho (processo terminado anormalmente), amarelo (processosendo inicializado) e branco (serviço não está ativo ou com situação desconhecida)

Process Startup Sequence

Seqüência básica do start do SAP Service Manager :• Na camada de serviços

• Verifica se os serviços básicos estão no ar (SAP<SID>_<SystemNumber> eOracleService<SID>)

• Aciona o SAP<SID>_<##>, que a Start Profile do sistema R/3 do qual o SIDadm é oadministrador e executa-a.

• Verifica e se necessário executa o script strdbs.cmd de inicialização do banco de dados • Verifica e se necessário executa o script msg_server.exe que coloca no ar o message• Verifica e se necessário executa o script disp+work que coloca no ar o dispatcher

• Na camada de processos• Com as informações da default profile e a instance profile o dispatcher (disp+work)

inicializa o R/3 criando os work process necessários e o serviço de gateway

As profiles estão no compartilhamento \\<sapGlobalHost>\sapmnt\<SID>\SYS\profile conhecidotambém como \usr\sap\SID\SYS\profile (se ignorarmos o disco onde está a instalação). Para o acessoremoto o compartilhamento a ser utilizado será o sapmnt, para o acesso local o compartilhamento aser utilizado é o saploc.

Se for necessário iniciar a instância através da linha de comando utilize o comando startsap que também possui seu inverso, o stopsap.

20

Parameter Read Sequence

A seqüência para a leitura dos parâmetros é a seguinte :• NT register• Ambiente do NT• Declaradas no start profile• Default profile• Instance profileO valor que será utilizado será o que aparecer por ultimo nesta lista. Para certificar qual o valor

assumido para um determinado parâmetro utilize o relatório RSPFPAR.

Resumindo, o SAP service lê as variáveis de ambiente, a start profile e a default profile; o R/3kernel (conhecido com dispatcher) lê a default e a instance profile. Se algum parâmetro for alterado,para ele passar a valer, tudo que for afetado deve ser reinicializado.

Logs and Traces

Logs and Traces for Database StartupPara saber o que aconteceu durante o startup do banco, além de erros e eventos do sistema,

procure pela log <drive:>\oracle\SID\saptrace\background\<SID>ALRT.LOG. Esta log é conhecidacom database alert file. Maiores detalhes sobre erros procure por <drive:>\oracle\SID\saptrace\usertrace\ora<####>.trc, que também é conhecido como oracle trace information. Em relação aosapdba, as logs ficam nos diretórios sapcheck, sapreorg e sapbackup.

Startup logs and traces in Windows NT Todas as mensagens geradas pelos serviços, SAP server manager ou outra aplicação do NT são

logadas no Event Viewer (utilizar o caminho Menu iniciar, programas, aplicação administrative tools(common), event viewer – eventvwr) nas logs de sistema, de aplicação e de segurança.

Startup logs and traces in R/3O diretório de work contém todos os arquivos de trace e de mensagens de erros da instância R/3..

• Arquivos de erros gravados pelo executável sapntstartb.exe que é acionado pelo SAP service manager ou pelo startsap :

• Stderr1 contém as logs do banco de dados• Stderr2 contém as logs do message server • Stderr3 contém as logs do dispatcher • Sapstart.trc contém o trace do programa sapntstartb. Vale lembrar que o nível do trace a

ser logado pode ser alterado pelo parâmetro rdisp/trace e este varia de 0 (no trace) até 3 (todas as mensagens e trace completo)

• Arquivos de trace :• Sapstart.log contém, de forma um pouco menos detalhada, a toda a log da inicialização • Dev_ms contém o trace do message server • Dev_disp contém o trace do dispatcher• Dev_w0 … n contém o trace de um work process especifico

Uma boa transação para ver as logs é a transação RZ03 e menu utility. Outra boa transação paraver mensagens de log é a SM21, mas esta mostra as mensagens de log de R/3.

Startup Diagnostics

As principais razões de falha durante o processo de inicialização são : • SAP Service Manager não consegue conectar com o SAP service. Normalmente ou ele não

está ativo ou não esta configurado corretamente.

21

• SAP service não inicia. Ou as entradas no NT register estão erradas, ou tem algum problemade configuração ou a senha está errada

• Database não inicia. Verifique as variáveis de ambiente, se o db está em dba mode, se algum arquivo foi perdido ou corrompido ou se o listener está desativado

• R/3 não inicia. Pode ser os compartilhamentos de disco, a configuração do serviço (porexemplo, usuário errado ou sem autorização), problemas de permissão nos arquivos, erro detcp (host, services, dns, etc) ou erro na conexão com o database.

Reasons for R/3 DowntimeEventualmente podemos parar o sistema para alterar a configuração e parametrização, para

manutenção de hardware ou sistema operacional ou para fazer algum tipo de upgrade.

Before stopping the R/3 system

Sempre que o sistema tiver que ser paralisado, certifique-se que :• Nenhum job está sendo executado ou perto de ser executado. Para isso use a SM37 para

verificar o schedule do R/3. Verifique se outros sistemas não podem estar próximos dedisparar jobs no R/3, via sapevt ou rfc

• Nenhuma atualização está em andamento. Para isso use a SM13;• Nenhum usuário está trabalhando no sistema. Para isso use a SM04;• Não existe atividade para o gateway. Para isso use a SMGW.

É bastante conveniente enviar mensagem para os usuários do que será feito. Para isso use aSM02.

Stopping the R/3 system

Para parar uma instância R/3 podemos faze-lo através do CCMS (que na verdade é a transaçãoSRZL) ou pelo SAP Service Manager (neste caso ele manda uma mensagem pelo named pipe para ainstância). A grande diferença do NT para o Unix é que o stopsap não para o banco de dados, ouseja, a pesar do startsap inicializar o banco de dados o stopsap não o paralisa.

Para o banco de dados podemos utilizar o sapdba ou alguma ferramenta do oracle, como OracleInstance Manager ou o Oracle Server Manager

Database Error Stopping Eventualmente, durante a paralisação do R/3 e do oracle, o oracle não consegue parar. Isto pode

ocorrer por que o banco de dados ainda está trabalhando na realização do rollback, ou porque umbackup online está sendo tirado, ou porque a área de archive está cheia. Normalmente este ultimomotivo (archive cheia) é o grande motivo de travamento do R/3 e a única solução para o problema é o

Backup off-line: database reconnect

Quando do backup off-line o R/3 pode ser configurado para não ser paralisado junto com o bancode dados. Isto é feito através dos parâmetros rsdb/reco_trials e rsdb/reco_sleep_time que configuram a quantidade de tentativas de recuperar a conexão e o tempo de espera por estaconexão. Com isto conseguimos que os buffers sejam preservados e as aplicações que estavamsendo executadas naquele momento não são abortadas. Na prática esta política está associada abackups com recursos de split mirrow de discos que contém os arquivos de dados do oracle.

22

Starting and Stoping R/3 – Unix Version

Operating System Tasks

O usuário <sid>adm é utilizado para administração do sistema R/3. O start do R/3 é efetuadostartsap_<host>_<instance nbr>, que fica no diretório home do usuário. Este

script tem um alias: startsap. O startsap verifica se o processo saposcol está rodando e o ativa, se necessário. O scipt pode ainda chamar o script startdb caso o banco se encontre em shut down. Emseguida o script starta a instância R/3. O script aceita 3 tipos de parâmetros:

• startsap R3, ativa apenas a instância R/3, desde que o banco esteja rodando • startsap DB, ativa apenas o banco de dados • startsap all, ativa o banco e a instância (é o default quando nenhum parâmetro é especificado

Um sistema R/3 possui basicamente 3 profiles que se encontram no diretório/usr/sap/<SID>/SYS/profile:

• Start profile: START_<instance>_<host>, que contém a relação dos componentes queserão ativados pelo sapstart na instância

• Default profile: DEFAULT.PFL, que contém alguns parâmetros globais do sistema• Instance profile: <SID>_<instance>_<host>, que contém parâmetros específicos da

Ao ativar o script startsap_<host>_<nn>, o seguinte processo é executado para levantar uma

• Ativa o programa sapstart• sapstart lê a start profile para ativar os serviços disponíveis na instância• Em uma central instance, o sapstart ativa o message server, o dispatcher, o collector e o

sender. Em uma dialog instance apenas o sender e o dispatcher serão ativados. Osprocessos sender e collector são utilizados para implementar o system log central do R/3

• dispatcher forka e cria processos child, tais como work processes e o gateway reader. Os work pocesses são criados de acordo com as informações da instance e da default profile. O gateway reader independe de parâmetros de profile, sendo sempre ativado

• Os work processes se conectam com a base de dados, que já se encontra rodando

Durante o processo de start, o sapstart grava no diretório de work um arquivo kill.sap que contémo comando kill ² <sapstart process nbr>, que será executado pelo script de stop da instância. Paragarantir um start consistente, a seqüência dos parâmetros lidos pelos work processes seguem umpadrão definido, conhecido como parameter replace sequence:

• São lidos os parâmetros hard coded nos fontes C do kernel• Parâmetros contidos na default profile sobrescrevem valores ja lidos no step anterior• Parâmetros da instance profile sobrescrevem os anteriores• kernel do R/3 (disp+work) lê os parâmetros contidos nas default e instance profiles. Desta

forma, alterações nelas executadas somente terão validade no próximo start.

Database Startup and Logs

Durante o processo de start, quando requerido, o startsap chama o script startdb que gravauma log apropriada no startdb.log. Eventos significantes (start, stop, errors) são logados pelo noOracle alert file: /oracle/<SID>/saptrace/background/alert_<SID>_.log. Informações detalhadas deerro são logadas no Oracle trace file: /oracle/<SID>/usertrace/ora_<pid>.trc. Quando se utiliza osapdba para start e stop do banco de dados, o sapdba grava uma log no diretório /oracle/<SID>/sapreorg, .../sapcheck, .../sapbackup, dependendo da ação que foi executada

R/3 Startup and Logs

O script startsap grava uma log de start no diretório home do usuário <sid>adm. O diretório dework contém trace files e error files de mensagens relacionadas com o start dos work processes e

23

demais serviços. O nível de informações gravadas nos trace files é definido pelo parâmetro rdisp/TRACE da instance profile. O default é 1 (errors e warnings), aceitando valores 0, 1, 2 e 3. Ocorreto acompanhamento das logs permite identificar o ponto onde ocorreu um erro no processo destart de uma instância R/3

Stopping R/3 Systems

As razões para se parar uma instância R/3 vão desde paradas planejadas (mudança na profile, manutenção do sistema R/3 ou DB, upgrades) até quedas não planejadas, por exemplo por falha dehardware. Antes de parar um sistema R/3 convém verificar os seguintes pontos no sistema. Havendo

• Verifique jobs background e batch input (SM37)• Estado da fila de update (SM13)• Informe os usuários (SM02)• Verifique os usuários logados (SM04, AL08)• Verifique interfaces externas

A parada do sistema deverá ocorrer primeiro nos dialog instances e posteriormente na centralinstance e database. O comando utilizado é o stopsap (alias do script stopsap_<host>_<nbr>) quepossui basicamente os mesmos parâmetros e funcionalidades do startsap (R3, DB, all). A paradaapenas do database (stopsap db ou sapdba) faz com que os work processes do R/3 interrompam aconexão com o Oracle. Estes processos tentarão uma reconexão (parametrizada por profile) e emcaso de insucesso, entrarão em modo de reconnect e somente tentarão nova conexão sob demanda.

O processo de retirar apenas o database poderá ser uma opção para efetuar o backup offline do banco de dados preservando porém os buffers da instância R/3 intactos durante o processo. Erros durante a tentativa de parada do database poderão ocorrer erros caso o Oracle esteja efetuando umrollback, executando um online backup ou ainda por se encontrar travado devido a falta de área para o archive. Caso a causa não possa ser identificada facilmente, utilize a SM21 para tentar identificar possíveis mensagens. De qualquer forma, elimine a causa antes de fazer novas tentativas deshutdown.

24

CCMS Configuration

Overview

O Computing Center Management System, conhecido como CCMS e acionado pela transaçãoSRZL, é a ferramenta que prove o gerenciamento de :

• Performance, monitoração e análise do R/3, sistema operacional e rede• Profiles, modos de operação e logon groups• Start/stop dos ambientes• Banco de dados e do archiving do banco de dados;• Carga de trabalho (workload) • Impressões• Segurança de acesso

Antes de utilizá-lo, em toda sua potencialidade, ele deve ser configurado. Para isto os principais

• Importar as profiles e adequá-las ao ambiente disponível para processamento• Definir os modos de operação do sistema. Normalmente definimos dois (diurno e noturno)

para balancear e distribuir a carga segundo o perfil de utilização de cada horário• Criar as definições dos perfis das instâncias com os seus respectivos parâmetros de

• Associar cada um destes perfis aos modos de operações• Definir a tabela de horários de entrada e saída de cada um destes perfis definidos no modo de

RZ10: Profile Maintenance

Esta é a ferramenta para manutenção das diversas profiles do R/3 (start, default e instance). Comela podemos editar e manter todos os parâmetros. A manutenção pode ser feita de forma básica ou estendida, o que difere é se os parâmetros serão manipulados de forma individual ou de formacoletiva. A transação ainda permite deletar, comparar e verificar as profiles e suas diferentes versões.

Lembrando, as profiles seguem o seguinte padrão de nome :• Start : START_DVEBMGS00_hostname• Default : DEFAULT.PFL• Instance : SID_DVEBMGS00_hostname

Os passos para a manutenção inicial das profiles são : Importa-las a partir do sistema operacional;Mante-las utilizando a RZ10; salva-las e ativa-las. Tomar cuidado com o botão import pois ele importa apenas o servidor corrente. Para importar use o menu Utilities, Import profiles, of active servers.

R/3 Profiles

A incorreta configuração do CCMS não impede o funcionamento do R/3, porém impede que oCCMS exiba dados úteis. A transação RZ10 do CCMS permite que se dê manutenção nas profilesdas instâncias do R/3. Ela mantém os parâmetros na base de dados do R/3 e a cada alteraçãoefetuada uma nova versão é gerada nesta base de dados. Quando ativamos uma versão de profileatravé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áriasversões de uma mesma profile, um histórico das alterações além de documentação dos parâmetros.

Em ambientes distribuídos com várias instâncias R/3, o diretório de profiles é compartilhado entretodas as instâncias e permanece como repositório central de todas as profiles. Para cada sistemaR/3 existem várias profiles. Uma DEFAULT profile e, para cada instância do ambiente, uma instancee uma start profile. Através da ferramenta RZ10, existem dois modos de exibição/edição das profiles:

25

• Em basic mode, os parâmetros que são alterados mais freqüentemente 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 seusnomes técnicos, mas apenas como campos em screen.

• Em extended mode, os parâmetros aparecem e são editados em uma interface tipo editor detexto, onde cada parâmetro é listado com o seu nome técnico e respectivo valor. Oadministrador 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 operacionalde acordo com os recursos do sistema (memória e CPU). Durante o processo de configuração inicialdo CCMS, importamos estas profiles para a base de dados R/3 utilizando a RZ10 e efetuamos asnossas customizações. Isto permite uma gerência 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 profileativa, 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 destainterface nunca diretamente no sistema operacional para evitar que haja dessincronização dasferramentas. Qualquer dúvida quanto ao sincronismo poderá ser verificado através de seus mecanismos de check e da comparação de versões.

Do ponto de vista do R/3, uma profile consiste de duas partes lógicas: entradas nas tabelas dabase de dados do R/3 e um arquivo no sistema operacional. Como a versão utilizada pelo startup é ado 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. Somente a versão mais recente de uma profilepode ser ativada pela ferramenta RZ10. Na prática isto significa que a tentativa de ativar uma versãomais antiga faz com que a profile seja copiada com uma nova versão e ativada. Qualquermanutenção vai sempre gerando novas versões na base de dados que ficam documentadas comocomentários e headers no file do sistema operacional.

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.

• sistema efetua um check automático de consistência entre a profile ativa e a base de dadossempre 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 nostipos 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 workprocesses 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 anecessidade de stop/start das instâncias para que as configurações tomem efeito.

Uma configuração básica de operation mode especifica os serviços ou tipos dos work processes eos períodos escolhidos para cada intervalo. É através desta funcionalidade que conseguimosconfigurar background work processes para processamento exclusivo de jobs classe A. Operationmode pode ser configurado baseado em alguns conceitos básicos:

• número total de work processes deve permanecer o mesmo entre os operation modes de umainstância, já que nenhum novo serviço será startado, apenas os processos terão suas funcionalidades reconfiguradas.

26

• Cada instância 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.

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 entreoperation modes pode ocorrer manualmente sob demanda do administrador do sistema através daRZ04 ou então de forma automática através da definição de um schedule de horários chamado detimetable, que configura um ciclo completo de 24 horas. Este schedule de horários é mantido através

SM63. A timetable é única para todas as instâncias de um sistema. Isto significaque todas deverão possuir a mesma configuração de operation modes, porém cada uma poderá ter asua configuração individual de work processes.

Além da timetable normal que configura o ciclo de 24 horas do operation mode, é possível definiruma timetable excepcional para ser ativada em uma data específica. Enquanto uma timetable normaldeve 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

Quando a mudança entre modos de operação ocorre, os work processes são distribuídosautomaticamente, sem necessidade de parada e restart das instâncias. Nenhum tempo é perdido porindisponibilidade do sistema, apenas o tipo dos work processes é alterado, permanecendo porém o

É possível simular o switch de um operation mode em test mode e desta forma analisar possíveisfalhas através da log de switch. Discrepâncias existentes na configuração das profiles ou na definiçãodos 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 instâncias R/3 de um sistema. Ainstância de banco de dados e pelo menos uma instância do ambiente precisam porém ter sidostartadas através das ferramentas do sistema operacional. Em plataformas UNIX é utilizada a facilidade de rexec para esta operação remota. Já no NT esta facilidade (rexec) não é padrão e deveser startada se precisarmos que uma instância NT manipule uma instância Unix. Além de permitir aparada de uma instância a RZ03 também permite o switch de operation mode manualmente.

27

Background Processing

Background Concepts and Features

Um job background é um ou mais programas ABAB, external programs ou external commands querodam seqüencialmente (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 ocorramtanto 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 workprocess livres para execução exclusiva de jobs classe A. O mecanismo de funcionamento é oseguinte: pelo menos x (configurado pela RZ04) work processes ficam reservados para classe A independente de quais serão eles.

Os jobs são disparados através de um serviço, o batch scheduler, que roda no sistema R/3. Esteserviço é um programa ABAP que roda em um dialog work process no servidor parametrizado nasprofiles do ambiente através do parâmetro rdisp/bcttime. Neste parâmetro é especificado o tempoem segundos com que este programa roda, normalmente 60 segundos. Quando se especifica umvalor 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 destafacilidade, os event-based jobs. A definição de quantos batch work process estarão disponíveis, semlevar em conta o modo de operação, está no parâmetro rdisp/wp_no_btc. Por definição um sistemaR/3 deve ter pelo menos 2 batch work process, independente de qual instância eles vão estar, paraatender o sistema de transporte. Se o sistema R/3 não for trabalhar com transportes não é necessárioter batch work process (mas isto é meio absurdo se pensarmos no dia-a-dia prático).

O mecanismo do batch scheduler, após a ativação, segue o seguintes passos :• Verifica a job-scheduling table ordenado por data de start, classe, servidor de destino e data

da criação do job;• Se o job for para ser executado na própria instância o dispatcher é acionado para alocar um

BTC, se o job for para ser executado em qualquer instância o message é acionado para determinar qual é o servidor com menor carga.

Operation Modes and Scheduling

O sistema efetua balanceamento de carga automática entre os servidores, a menos que seespecifique o server target do job. A especificação do server durante o schedule faz com que o jobtenha prioridade sobre outros da mesma classe sem a especificação explícita do server. É possívelconfigurar operation modes (através da transação RZ04) para efetuar um switch entre workprocesses de dialog e batch em horários pré determinados sem a necessidade de um stop/startdo 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çãoSM36. Ao efetuar o schedule do job é possível especificar o nome de quem irá receber o spoolrequest (opção Spool list recipient) que tanto pode ser um usuário R/3 quanto um mail do SAPOfficeou mail externo. Os Programas ABAP que requerem um determinada entrada de dados paraexecução poderão ser schedulados em background bastando que se informe uma variant (lista de parâmetros) para processamento. Eventualmente o schedule pode ser acessado pela transaçãoRZ01 que é um visualizador gráfico dos jobs que estão schedulados.

Quando um job background executa comandos ou programas externos, o R/3 starta o programaserver SAPXPG no host target através de chamadas RFC. Programas externos somente podem serexecutados por usuários com autorização para background administrator. Comandos externos podem

28

ser executados por usuários com autorizações R/3 apropriadas. Os programas externos somenterodam em modo síncrono e os comandos externos rodam tanto em modo síncrono quantoassí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 • Em um modo de operação especifica• Com periodicidade, etc

Events in Job Scheduling

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

Através da transação SM62 podemos definir os user events e a transação SM64 é utilizada paradisparar os eventos. O programa sapevt (Unix ou NT) é utilizado para disparar um determinadoevento 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 conectaao message server da instância via tcp/ip para disparar o trigger no R/3. Internamente em umprograma ABAP é possível ainda disparar um evento a partir da , aBP_EVENT_RAISE.

Da mesma forma que o R/3 utiliza o SAPXPG para startar programas no sistema operacional oSAPEVT também utiliza o SAPXPG para startar eventos no R/3. Com isto é possível concatenar ossteps e schedular os jobs de forma a atender praticamente qualquer necessidade de schedule.

Changing or Monitoring background Jobs

Changing background job

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. Jobsque estão rodando ou que já foram processados não podem ser alterado. Os jobs que estão rodandopodem ser capturados, ou seja, debugados e eventualmente cancelados. Os jobs que já terminaram,

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 aquelaexecução. A Spool list exibe a saída da execução. A lista exibida na SM37 depende dos critériosmarcados na tela inicial. É necessário uma especial atenção para a seleção dos jobs que nãopossuem uma data de start e para aqueles que dependem de algum evento (colocar * no evento eclicar nas opções de jobs sem data e com predecessores). Outro ponto a ser observado é a diferençaentre um job released e um job ready. O released já pode ser rodado, em função da marcação dohorário e das autorizações, mas não está na hora de ser executado. O ready já pode ser rodado mas ainda não foi atribuído para o work process que está disponível (provavelmente o dispatcher está muito ocupado). De qualquer forma o tempo na situação de ready é mínimo.

29

Para ver os jobs existe também o Job Scheduling Monitor (RZ01) que exibe em modo gráfico oschedule nos vários servidores que compõem o sistema ao longo do tempo. Esta transação tambémpode ser 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 ApplicationProgramming Interface, ou Job API. Através do Job API é possível por exemplo rodar jobsseqüencialmente ou ainda incorporar lógica de decisão no ambiente de processamento ( O R/3 nãoconsegue tratar schedule de jobs muito complexos. Um exemplo disto é um job que precisaria de doispredecessores). As funções ABAP para o Job API se encontram no ABAP workbench com o nome BP_*. O XMI ou External Monitoring Interface é um conjunto de módulos de funções que agregamtodas as funcionalidades para interface externas de gerenciamento do CCMS

O 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 comos Job APIs. Ferramentas externas de job scheduling (XBP) permitem que se integre em um únicoambiente 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 eadministraçã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 estaautorização com field setado para “Y” pode administrar jobs em todos os clients do sistema enã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, PLAN e SHOW)• S_ADMI_FCD: funções especiais para o administradordo sistema que devem ser utilizada

somente pelo pessoal de basis• S_RZL_ADM: administrador do sistema (CCMS)

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

(01 equivale a all e 03 a display) • S_LOG_COM que possui fields que autorizam a execuçã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

• S_XMI_LOG define se o usuário pode acessar interfaces XMI e como este acesso será feito

Dicas sobre jobs• Ao executar um comando do sistema operacional utilize “cmd /c dir”• Quando o resultado de um comando externo não aparecer verifique os flags (aguardar o

retorno)

30

System Monitoring

What, why, who and when

Os principais focos de monitoração são : • R/3 (application servers, buffers, …)• Database (performance, buffers, backups, …)• Operationg system (cpu, file system, hardware contention, …)

A monitoração no R/3 4.0 é feita de uma forma simplificada através de uma grande arvore que iramostrar, através de suas folhas, os diversos item que devemos estar atentos em todo o ambiente. Agrande vantagem desta arvore é a hierarquização e categorização de todos os elementos (tree elements e objects) que são relevantes, seus parâmetros de valores (Attributes) e a capturaautomática e centralizada de todas as informações e um ponto de acesso unico para a tarefa de

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. Amonitoração dos diversos componentes e ferramentas do ambiente R/3 é uma operação necessáriaexecutada pelos administradores do sistema para melhorar a performance, garantir a disponibilidadedo 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 dokernel 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 quesumariza em seus nós as diversas áreas de atuação. Esta monitoring tree agrega atributos em seusnós que podem ir sendo detalhados até chegar a granularidade mínima da entidade monitorada. Umalert 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 maiselevados. É necessário portanto ir efetuando operações de drill down no Alert monitor até identificar oatributo que gerou a mensagem. É previsto para releases futuros do R/3 que a funcionalidade domonitor 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 ferramentasde 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 objetosfí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 MTEclass 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 objetospertencentes a uma determinada classe, evitando assim redundância de definições. Os atributoscomuns também podem ser agrupados em customizing groups aos quais são associados thresholdspara os alerts e textos de alerta. Uma vez configurados os alerts, é possível então associar tools aos

• Coletar dados• Analisar os alerts• Reagir aos alerts (OnAlert tool)

As ferramentas podem ser associadas aos MTE classes ou a um MTE individualmente. Estasferramentas tanto poderão ser ferramentas standard da SAP quanto ferramentas definidas e criadas

31

pelo usuário. A árvore básica de monitoração contém o Basic monitor, porém o usuário pode criarsuas próprias árvores customizadas de monitoração.

Tool Assignment

Para adicionar uma ferramenta ou uma classe na MTE devemos seguir os seguintes passos :• Definir a ferramenta e especificar o tipo da ferramenta (relatório, função, módulo, transação,

programa, etc), a localização (servidor, banco de dados, etc) e modus operandis (background,foreground, manual)

• Liberar a transação para a finalidade• Associar a ferramenta a classe ou ao no MTE. Isto facilita o acesso a ferramenta pois voce vai

aciona-la diretamente. Eventualmente voce pode herdar esta definição de outra arvore ou até

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 basissystem, R/3 ABAP e R/3 system log.

As principais transações e métodos para monitorar o sistema são :• A system log (transação SM21) contém informações referentes ao sistema R/3 e suas

instâncias e exibe mensagens categorizadas por classes: S (R/3 start/stop/operation modeswitches), W (rollback perfomed), K (kernel program error) e T (ABAP transaction error). NoNT a transação mostra o log (/usr/sap/SID/dvebmgs00/log/slog00.log) apenas da instânciacorrente. No Unix ela pode mostrar as logs de todas as instâncias

• nó R/3 services provê informações sobre os work processes do sistema. A transação SM51nos dá um overview (incluindo a queue do dispatcher, system log, remote logon, etc) dasinstâncias disponíveis enquanto a SM50 analisa os work process de uma instância específica.A SM66 oferece um overview de todos os work processes ativos (se for necessário o defaultpode ser alterado para ver todos ou em um status especifico) em todos as instâncias dosistema.

• A SM04 e AL08 nos dá um overview dos usuários logados no ambiente R/3. A SM04 mostraos usuários de uma determinada instância e a AL08 de todas as instâncias ativas.

• processo de update no R/3 é usualmente executado em modo assíncrono, onde os dados sãoescritos em tabelas intermediárias (VB* tables) e posteriormente transferidas para a base dedados pelos work processes de update V1 e V2. A transação SM13 permite a monitoração dafila 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ãorecomenda que se proceda ao restart da transação pelo usuário.

• R/3 possui seu próprio mecanismo de lock que fica residente em uma tabela na memória dainstância que contém o processo de enqueue. Os locks podem ser monitorados através da

SM12. Os locks que permanecem no sistema poderão ser eliminados manualmenteapós exaustiva verificação das causas, uma vez que o procedimento normal é quando oslocks postados são eliminados automaticamente pelo update das tabelas ou cancelamento da

• A transação ST22 permite que se analise os dumps de programas ABAP. Através destaanálise é possível identificar o erro pela análise dos campos e variáveis envolvidos eeventualmente procurar no OSS por notas que corrijam o problema.

• A ST03 é o workload monitor que permite analisar os tempos de resposta. As estatísticas dostempos de resposta das transações são apresentados de forma detalhada e estratificadas por componentes (rolltime, wait time, DB time, processing time e load time) permitindo a rápidaidentificação de possíveis gargalos no ambiente R/3. As estatísticas apresentadas pela ST03permanecem em um arquivo do sistema operacional (file stat no diretório data da instância) e são recolhidas e consolidadas de tempos em tempos pelo programa RSCOLL00 scheduladono ambiente. Este programa se baseia na tabela TCOLL para disparar uma série de outrosprogramas satélites que efetuam as mais diversas tarefas de consolidação por níveis detempo/data.

32

Users and Authorization in the R/3 System

Users in the R/3 environment

O Ambiente R/3 possui várias formas de controle de acesso mas devemos lembrar que o R/3 estásendo executando em um sistema operacional e utiliza um banco de dados como repositório eportanto devemos observar os aspectos de segurança nestes ambientes e na inter-relação entre oR/3 e eles.

Devemos tomar cuidado com os usuários do sistema operacional (normalmente SIDadm) e dobanco de dados (sys/change_on_install e system/manager) tanto na central instance quanta nosapplications. Com estas chaves podemos acionar utilitários no sistema operacional, como sapevt, eacessar o banco de dados diretamente a partir de utilitários do oracle. Do lado do R/3 temos que teros mesmos cuidados pois uma brecha na autorização pode permitir que uma chave no R/3 acabe porter acesso ao sistema operacional e aos mesmos utilitários mencionados anteriormente.

Uma das primeiras atividades após a instalação do sistema é a troca das senhas dos usuários(SIDadm, sys, system, sap, sap*, ddic e earlywatch).

.

Authorization Concepts

As autorizações existem para limitar o acesso a transações e objetos do sistema R/3 quenecessitam de proteção. As autorizações são agrupadas em profiles e estas profiles são associadasao master record do usuário. Autorizações podem ser no nível da transação ou nos mais diversosní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ãoagrupados 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 dotipo positivas, ou seja, efetuam grants para o usuário e não revokes, ou seja, se duas autorizaçõesforem dadas, uma mais restritiva e outra mais ampla, vale a mais ampla. Um user master record pode possuir uma ou mais profiles, que podem ter sido geradas através da definição de activity groups

PFCG) ou manualmente. Uma profile pode ainda ser composta de mais de umaprofile (composite profile) mas limitada a um máximo de 150 profiles. As profiles são associadas aousuário tanto manualmente através da SU01 quanto durante o processo de geração e manutençãodas activity groups.

Eventualmente pode ser necessário criar objetos de autorizações além do standard. Para issousamos a transação SU21 para manter objetos de autorizações e a SU20 para manter os campos

Em relação aos papéis dos administradores de segurança no sistema poderíamos dividir aadministração em três níveis, a saber :

• Administrador de usuário: responsável por manter os dados dos usuários, por associar osgrupos de atividades e as profiles aos usuários e atender aos chamados dos usuários

• Administrador de profiles: responsável por manter os grupos de atividades e as profiles deforma genérica sem entrar no mérito dos valores atribuídos as responsabilidades e atendo-se

• Administrador dos dados da autorização: responsável por manter os valores dentro dasresponsabilidades dos grupos de atividades

Desta forma o superuser poderia delegar grande parte das tarefas para se dedicar as demaisatividades de basis e os demais administradores poderiam entender bem mais das questões

33

semânticas associadas as autorizações aplicadas a cada função a ser desempenhada pelos

Authorization as ER

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 instância) e são verificadas a cada transação ou atividadeexecutada pelo usuário. Antes que uma determinada transação ou operação ocorra, os fields doauthorization object são checados contra os fields do usuário para aquele mesmo objeto deautorizaçã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

Para simplificar, podemos entender que a verificação de segurança ocorre nos seguintes empassos :

• Para ganhar acesso a transação• Verifica se o usuário está autorizado a acessar a transação através da verificação do objeto

s_tcode• Verifica o objeto associado a transação em questão e se o usuário tem autorização para este

objeto e quais são elas. Ex. O usuário possui o s_tcode para mm01, mas possui o valor 03para o campo actvt do objeto m_mate_sta

• Durante o processamento do código abap• Verificação das autorizações verificadas pelo comando abap authority-check

Algumas outras dicas isoladas de autorizações : • Durante um call transaction os dois primeiros passos, relacionados a segurança da transação,

• Se o buffer do usuário for pequeno demais (veja parâmetro auth/auth_number_in_userbuffer)algumas autorizações podem ser perdidas

• Se for necessário cancelar a verificação do s_tcode utilize o parâmetroauth/no_check_on_tcode

• Se for necessário saber quais autorizações estão carregadas no buffer utilize a transaçãoSU56 e se for necessário saber qual autorização está faltando utilize a SU53

Dicas de tabelas: Tabela TACT contém todos as atividades possíveis no r/3 e a TACTZ contém o relacionamento das atividades possíveis para um objeto

Profile Generator

O profile generator (PFCG) é uma ferramenta que simplifica a administração de segurança atravésde uma visão voltada para o menu de transações da empresa permitindo que de forma mais interativase crie e associe profiles para usuário ou grupo de usuários que executam determinada função. Este

Transaction

Classes

Authoriz.

Fields

Values

Objects

Profiles Users

1-n na task en-n no código abap

34

grupo lógico de funções comuns que possuem profiles comuns são denominados Activity Groups. Umusuá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 objectsnecessários para aquela atividade e os associa a profile que será gerada. Caso os fields sejamcustomer-independents, o sistema já provê os valores necessários para a atividade, caso contrário osvalores precisam ser completados pelo administrador durante o processo de geração. Ao gerar umactivity group o administrador de segurança deverá checar os valores propostos pelo sistema para osdiversos 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 umamesma 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 simplificaa administração de segurança. Neste caso os usuários são associados a responsabilitie e não maisao activity group. Isto significa que caso grupos distintos de usuários que efetuam as mesmastransações em um sistema R/3 diferindo apenas nas autorizações para operações permitidas dentrodestas transações não mais precisam ser administrados a partir de activity groups distintos, mas simatravés de responsabilities distintas dentro do mesmo activity group. Neste tipo de administração, asautorizações para transação são associadas apenas uma vez no activity group para os diversosusuá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:• primeiro nível contém as object class, por exemplo “Standard Finantial Accounting - FI”• segundo nível contém os authorization objects, por exemplo “Customer: Authorization for

• No terceiro nível contém authorizations, por exemplo “Customer: Authorization for companycodes – T.....” e abaixo dele o sistema lista todos os fields com seus respectivos valores

Nesta lista é possível dar manutenção nos valores (clicando no lápis) ou ainda obterdocumentaçã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 listadas transações daquele activity group que necessitam deste objeto de autorização.

O profile generator possui outra característica. Nele é possível fazer o apontamento para osusuários que irão possuir um determinado perfil. Neste caso devemos executar o programa RHAUTUPD para rever as profiles e task profiles dos usuários. Na prática o programa varre ocadastro de usuários removendo todas entradas relacionadas ao grupo de atividade que esta sendotrabalhado e depois insere-as novamente. Se for necessário fazer isto para todos os grupos deatividades devemos utilizar a transação PFUD, que aciona o programa RHAUTUP1. É recomendadoque este programa esteja agendado para rodar diariamente durante o periodo noturno. Com istotemos a garantia que os apontamentos sempre estarão corretos.

Os principais passos para a criação de um perfil, também conhecido como activity group, são :• Especificar as atividades que serão desenvolvidas a partir dos caminhos de menu• Criar as responsabilidades (opcional)• Criar a authorization profile• Associar os usuários ao activity group• Atualizar, utilizando o rhautupd, o mestre de usuários

Devemos procurar sempre alterar o nome gerado pelo standard para facilitar o compreendimentoe a localização. A SAP sugere que o nome sempre começe por S_.

O profile utiliza as cópias de algumas tabelas standard (USOBT e USOBX) para trabalhar. AUSOBT_C contém os objetos que precisam ser verificados e a USOBX_C os valores necessários aosobjetos. Estas tabelas podem ter seus conteúdos mantidos pela transação SU25. Já a transação SU24 pode ser utilizada para ajustar os checks dos objetos. Como ilustração, a transação SU24mantém o tipo de check que será feito, a saber : U – não é mantido; N – não é checked; C – écheckado mas os valores não são mostrados no profile generator e CM – o check é feito e o profile

35

User Master Record

Através da transação SU01 é possível dar manutenção nos usuários. As informações estãoagrupadas por identificação e localização, dados de logon, defaults, task profiles, profiles e

SU3 (ou System � User profile � Own data) permite que o própriousuário altere seus dados, tais como Address, Defaults e Parameters, sem violar a segurança de acesso estabelecida pelo administrador.

Lembrar sempre que se for associar uma task ou responsibility (profiles geradas por profile generator) a um usuário, o correto é faze-lo pela pasta de task profiles. Se a inclusão for feita pela pasta de profiles a autorização vai funcionar mas na próxima reconciliação (execução do rhautupd) este dado será perdido pois vai prevalecer apenas as profiles adicionadas na task profiles.

Settings for System Profile Parameters

Diversos parâmetros configuram o funcionalidade de segurança no R/3, a saber :• Configurar o tamanho mínimo da senha, login/min_password_lng com default 8• Marcar de quanto em quanto tempo a senha deve ser alterada,

login/password_expiration_time• Bloqueio de usuários após logons incorretos, login/fails_to_user_lock com default 12• Fechar a sessão após logons incorretos, login/fails_to_session_end com default 3• Desbloqueio de logons incorretos, login/failed_user_auto_unlock com default 1 (desbloqueia),

a meia noite• Bloquear o sap* de logar no sistema, login/no_automatic_user_sapstar com default 0• Existem diversos outros parâmetros para configurar o sistema de segurança de login do R/3.

Para maiores informações pesquise a nota 66533 e a 68048. Outra boa dica é a remoção do sap*na tabela usr02. Com isto, e a alteração do parâmetro que impede do sap* logar, voce pode utilizar osap* com a senha pass.

A transação SUIM exibe, através da SARP ou SU01->information, a lista de todos os usuáriosbloqueados no sistema e mais uma dezena de relatórios de usuários, profiles e outros relacionadosao tema.

Security

Os clients 000 e 001 possuem os users SAP* (pwd 06071992) e DDIC (pwd 19920706) com, pordefault, autorizações SAP_ALL, devendo o administrador alterar suas senhas na instalação. O client066 utilizado pela SAP para consultoria remota possui o usuário EARLYWATCH (pwd support) que

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(USR02) do sistema, este usuário pode ser usado para efetuar logon como SAP_ALL. Por razões desegurança portanto é interessante que sempre tenhamos um usuário SAP* definido em cada client. Anota 68048 sugere um parâmetro (login/no_automatic_user_sapstar) que quando especificadosuprime a possibilidade de utilização deste SAP* hard-coded. Porém sempre que se for criar um novoclient é necessário permitir a existência desta feature hard-coded para que se possa logar no novo

Information System e Authorization Traces

O R/3 permite que se check quais verificações de segurança estão sendo efetuadas em umadeterminada 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) ou

ST01. O log é gravado no diretório \usr\sap\SID\DVEBMGS00\log\trace*.log.

36

Para uma analise localizada de falha de segurança pode-se utilizar a transação SU53, que exibequais authorizations são requeridas em determinada task. A transação SU56 exibe o buffer deautorizaçã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 � Masschanges � Reset all user buffs)

• Se o buffer não está muito pequeno. O parâmetro auth/auth_number_in_userbuffer define o número de entradas reservada nesta área para cada usuário, devendo ser aumentado se for ocaso

Ao se criar um usuário pela SU01 deve-se especificar a sua categoria, se Dialog, BDC (batchinput), Background (batch jobs) ou CPIC (para conexão remota). Algumas destas categorias temcaracterísticas próprias, como dialog ou background, mas servem também como informaçãodocumentacional.

Password Rules

Existem uma série de parâmetros para configurar o tratamento que o R/3 vai dar a senha dousuário. Além da lista abaixo ainda podemos fazer uso da tabela USR40, através da SM30, parainserir palavras ou seqüências de caracter que não poderam ser utilizadas na senha. As entradas naUSR40 podem também fazer uso de wildcards como *. Além disso temos as seguintes regras :

• Tamanho mínimo da password (login/min_password_lng) com default 3• Primeiro caracter diferente de ! e ?• Os tres primeiros caracteres não podem ser o mesmo nem ser iguais a parte do user name• Não pode ser sap* ou pass• Número máximo de erros na senha para fechar a sessão (login/fails_to_session_end) com

default 3• Número máximo de erros na senha para bloqueio da chave (login/fails_to_user_lock) com

default 12• Libera os usuários que estão bloqueados por logon incorreto a meia-noite

(login/failed_user_auto_unlock)• Número de dias para que a senha expire (login/password_expiration_time) com default igual a

0, que significa que nunca expira

O R/3 também já vem preparado (hard coded) para impedir uma série de outras senhas, a saber :

Profile Generator Setup

Para ativarmos o profile generator devemos seguir alguns passos, a saber :• Gerar o enterprise IMG através da SPRO, se ninguém tiver feito. Provavelmente o time

• Ativar o profile generator através da inclusão do parâmetro auth/no_check_in_some_cases = Y

• Desativar a solicitação a todo instante de chance request pelo profile generator através da

• Criar a classe de desenvolvimento utilizando a transação OY08• Criar as cópias das tabelas standard (USOBX e USOBT) que o profile generator necessita

para gerar os grupos de atividades, utilizando a transação SU25• Alterar os check indicators e os valores dos campos dos objetos de autorizações• Criar o menu da companhia para o profile generator utilizar

Transporting Authorizations and Users

Devemos sempre ter em mente que os grupos de atividades podem ser transportados mas ocadastro de usuários não. Com isto temos um inconveniente que quando transportamos o grupo de

37

atividades perdemos o link com os usuários que possuem este grupo no ambiente de destino. Poroutro lado, podemos levar todo o cadastro de usuários de um mandante para o outro. Isto pode resolver problemas pontuais mas não resolve o problema da manutenção das profiles que estão naprodução e nem do ciclo normal de trabalho com os grupos de atividades.

Para transportamos um grupo de atividade, lembre-se ele foi desativado pela transação OOCR,devemos clicar no icone do caminhão na transação PFCG para transportarmos um grupo de atividadeespecifico. Para transportamos um conjunto de grupos de atividades devemos utilizar o programaRHMOVE30 que possui diversas formas de seleção. Após importarmos a change que foi gerada noambiente de destino devemos executar a transação SUPC para regerarmos a profile. Neste caso,quando geramos um grupo de atividade que veio do ambiente de desenvolvimento, precisamosatualizar a tabela T77TR (utilizando a SM31) para que o transporte fique configurado para não perder a associação com os usuários no ambiente de destino nos próximos transportes deste grupo deatividades.

SAPRouter

O SAPRouter é um componente de software que vem com o R/3 ( no unix é um script que podeser adicionado no startsap e no NT é um serviço que deve estar ativo) para viabilizar a ligação deduas redes com a garantia de segurança e proteção de acesso em cada uma delas pelo proprio parceiro.

Com o SAPRouter voce pode :• Controlar e logar as conexões com o sistema R/3• Permitir que outros saprouters tenha acesso a uma rede específica• Proteger o sistema contra conexões e envio de dados de usuários não autorizados• Encripitar senhas e outros dados por parceiros certificados pela SAP• Controlar o acesso ao serviço de OSS da sap

Para utilizar o SAPRouter precisamos criar o diretório saprouter debaixo da arvore \usr\sap; obtera versão mais nova disponível no OSS e criar a tabela de rotas permitidas no arquivo \usr\sap\saprouter\saprouttab. Esta tabela é que contém a definição de quem poderá ou não passar de um lado para o outro. Ela é um arquivo texto com cinco campos, a saber : Permit/Deny/Secure, endereço de origem, endereço de destino, serviço e password. Os endereços podem tanto serhostnames com ip e neste ultimo caso podemos utilizar também os wildcards para selecionarmosuma rede inteira (Ex. 123.45.*). Já o serviço e a password são opcionais, sendo que o serviçoassume o defalt de 3299 que é a porta padrão utilizada normalmente para saprouter. A grande dicana construção da routtab é a definição do que é proibido no inicio do arquivo e do que é permitido nofinal. Isto é necessário por que a leitura e decisão é feita do primeiro para o ultimo.

Para especificarmos uma rota para o saprouter devemos utilizar o mesmo padrão utilizado noSAPGUI. A única novidade é a chave /W/ para conter uma eventual password a ser passada a umsaprouter. Para testar a rota podemos utilizar a dobradinha “niping –s” no host origem e “niping –c –H<host_origem>” no host destino ou simplismente niping –c –H /H/<saprouter>/H/<host_destino>. Osaprouter possui uma série de variações de parâmetros. Elas podem ser obtidas simplismenteacionando o saprouter na linha de comando sem parâmetros. Algumas delas são importantes como – R para dizem onde esta a routtab, -r para startar o serviço, -s para parar o serviço, -r –V3 paraselecionar o nível mais alto de trace, -t para ativar o trace, -T para dizer onde vai ser gravado oarquivo de trace e –G para dizer onde será gravado o arquivo de log.

SNC secure Network communication

A SNC interface permite que o sistema R/3 passe a utilizar algoritmos de criptografia para osdados que irão transitar na rede e para autenticar as senhas de usuários. Normalmente o R/3 não faz criptografia de dados e a senha transita pela rede como caracter.

O SNC é uma camada na arquitetura R/3 que estabelece um padrão de interface para ossoftwares de segurança e autenticação de usuário disponíveis no mercado. Atualmente os softwarescertificados pela SAP são o Kerberos 5 do MIT e o Secude 5. Para maiores detalhes veja a nota

38

66687. O padrão SNC prove três níveis de segurança, a saber : A autenticação da comunicação entre os parceiros sem a proteção do dados que será trocado; Integridade que garante a autenticação e mais uma assinatura digital da informação que está trafegando para garantir sua autenticidade; eConfidencialidade que garante a autenticação a integridade e a confidencialidade que o dado nãopode ser interpretado por outro que não sejam os parceiros da comunicação.

Para ativarmos o SNC temos que definir qual será o padrão de nome dos usuários. Podemosescolher entre X.500 (que distingue o nome pela formação de diversos elementos), nome@dominio (que usa uma concatenação simples do nome do usuário e de seu domínio) e o padrão de nome externo do R/3. Além de definirmos o padrão de nomes temos que incluir o parâmetro snc/enable = 1na default profile para ativar efetivamente o SNC. Com isto a SU01 passa a possuir mais uma pasta que contém o nome SNC do usuário. Podemos ainda alimentar a tabela USRACL, que contém o de-para, diretamente com o nome interno e o nome externo dos usuários. Para os usuários RFC e CPIC podemos definir apenas um usuário interno para vários usuários externos através da tabela USRACLEXT. Podemos também ativar níveis de insegurança para alguns casos. Por exemplo,aceitar sessões não seguras através do parâmetro snc/accept_insecure_gui =1 ousnc/accept_insecure_cpic = 1. Além da SU01, outras transações passam a possuir maiores detalhessobre o SNC, a saber : SM59 que controla as chaves RFC; a SM54 que controla as chaves CPIC e aSNC0 que controla a lista de acesso entre sistemas R/3.

A utilização do SNC pressupõe a instalação de uma dll (secure.dll) junto com o SAPGUI além docliente do software de segurança que será utilizado. Para o saplpd temos que incluir na cliente umaentrada no win.ini que habilita o uso do SNC pelo saplpd e indica a dll que irá interfacear com o

No geral devemos seguir algumas recomendações para implementar o SNC. A primeira é nuncamisturar applications que utilizam SNC com outros que não utilizam. A seguinte é ter certeza que o produto de segurança está apto a trabalhar com os padrões de nomes estabelecidos pelo R/3; E porfim garantir as definições do nível de proteção desejado, dos parceiros e protocolos que serãoimplementados, quais conexões serão protegidas e as respectivas portas a serem bloqueadas pelo

39

Software Logistics

R/3 System, Servers and Instances

Uma instância R/3 é um grupo de serviços que são inicializados e parados simultaneamentepor um dispatcher, possuindo em comum uma profile de instância. O nome de uma instância écomposto pelos nomes que identificam os serviços (Dialog Update (Verburren em alemão) Enqueue Background Message Gateway) por ela executados. Uma central instance contémtipicamente todos os serviços R/3 instalados, daí o seu nome ser DVEBMGSnn, já uma dialoginstance possui o nome Dnn, onde nn é o system number utilizado para compor o número das portasque efetuarão as chamadas ao dispatcher (32nn) e ao message server (36nn) na camada TCP/IP. Um server pode conter uma ou mais instâncias R/3 configuradas. Um PC com o frontend SAPGUIinstalado também é considerado um server da camada presentation na arquitetura R/3. O databaseserver é um hardware que possui o RDBMS relacional instalado. É comum em R/3 instalarmos odatabase server no mesmo host que contém a central instance. O conjunto de todos estesservidores com suas respectivas instâncias 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, os transactional, customizing e user master data. • 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 sistemaR/3. Seus dados são client independents. Os programas ABAP armazenados no dicionário sãocompilados uma vez no primeiro acesso (early binding) e ficam armazenados em um outrorepositório de executáveis (tabelas D010*). Cada alteração em um programa força a sua

posterior. Este procedimento denominado late binding épossível através de um mecanismo de comparação de timestamp. Este mecanismo de early binding elate binding garante que a integridade das informações contidas no dicionário ABAP não afete aperformance do sistema, uma vez que os executáveis de telas e programas são mantidos atualizadosautomaticamente 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. Istopermite que um único sistema R/3 administre vários clients diferentes, cada um com seuspróprios dados.

Como a base de dados (consequentemente as tabelas) é em um sistema R/3 os dados dosdiferentes clients ficam armazenados no mesmo local e são diferenciados pelo kernel do R/3. Naprá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 chamadaa estas tabelas o sistema incorpora na clausula WHERE do SQL o campo MANDT = ‘nnn’. A únicaexcessão é a tabela T000 que defini quais são os clientes existentes na instância e é uma tabela com

Este campo que identifica um client é composto deque sempre que efetuamos um logon informemos o número do client. Este campo étela de login inicial do R/3, juntamente com a chave e a password do usuário. Como os dados declients diferentes funcionam no R/3 como bases de dados diferentes (separação por kernel), asempresas quando desejam implementar uma administração coorporativa de suas subsidiárias, ocontrole centralizado é possível através de uma outra facilidade que é o campo configurável

40

denominado company code. Este campo define a menor unidade administrativa com que osrelatórios externos podem varrer para uma visão centralizada.

O conceito de authorities do R/3 sobre este campo company code permite ainda que umacompanhia matriz acesse as suas filiais com finalidades de consultas ou auditoria impedindo que asdiversas subordinadas tenham acesso aos dados umas da outras.

Standard Client Roles

É 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 pelos times funcionais e de abap. Neste client podemos fazer alterações no ambiente e gerar change request

• 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. Neste client podemos fazer alterações mas nãopodemos gerar change request

• Client TEST, para teste de customizações com uma massa reduzida 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 compreendendonormalmente 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 ecustomização consistente. Por questões de segurança, é aconselhado proteger o sistema utilizando oconceito 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 deimplementação do desenvolvimento, qualidade e produção. Além das questões óbvias de segurançae performance do ambiente produtivo, tal implementação protege o sistema evitando queconfigurações client independents do ambiente de desenvolvimento sejam implementadas na

Uma implementação em dois ambientes também não é aconselhável porque todos os objetostransportados para o ambiente de consolidação ficam imediatamente valendo no 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 3adicionais:

• Um host composto de três clients (SAND, TEST, CUST) onde fica o ambiente dedesenvolvimento

• Um host de quality assurance (com dois clients QTST e TRNG) onde os novosdesenvolvimentos são testados antes de serem migrados para o ambiente produtivo

• Um host para o ambiente de produção – com o client PROD

Os sistemas R/3 que compõem um mesmo landscape devem possuir system IDs diferentes para acorreta 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 econfigurados de acordo com as necessidades de cada empresa para atender e se adequar ao seuramo 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 entretodos os clients que compõem o landscape da empresa, garantindo assim a consistência do sistema.

41

Transport Management

Transport Process

O TMS é a ferramenta existente no R/3 onde estão centralizados todos os recursos para efetuar egerenciar os transportes no ambiente. Até o release 3.1H os transportes eram efetuados através deferramentas no sistema operacional e baseava-se nas configurações das tabelas TSYST, TWSYS,TASYS e DEVL principalmente.

O primeiro passo no processo de transporte é o release dos change requests que sãoexportados para files do diretório comum de transporte (\\hostgroup\sapmnt\trans). Para cadachange liberado, arquivos são gerados nos subdiretórios data (dados exportados) e cofiles (controlfiles). Este diretório de transporte também possui um subdiretório buffer que contém um import bufferfile para cada sistema que compartilha aquele transport group. Cada change liberado acrescenta uma entrada neste file de forma que ele conterá informações sobre os transportes que estão disponíveispara import e a seqüência de importação. Esta informação é acessada no TMS através da facilidadedas import queues

A rota de consolidação nas quais os transportes são liberados normalmente especifica um sistemade quality assurance para validação das changes. Quando se efetua o import do transporte para estesistema QAS, o sistema coloca as entradas no import buffer do sistema de delivery, normalmente oPRD, ou algum outro especificado no TMS. O processo de validação no sistema QAS poderá detectar erros que serão corrigidos no DEV e novamente transportados para consolidação. A fila de import dosistema PRD poderá então conter mais um import que deverá ser efetuado.

Um ciclo de alteração poderá conter um ou mais change requests, dependendo da necessidadede correção após os testes no QAS. Quando finalmente o processo estiver pronto para import nodelivery (PRD), o TMS permite que toda a fila de import seja efetuada carregando o sistema deprodução com a versão final do objeto. Para o correto funcionamento deste mecanismo éimprescindível garantir que os transports sejam importados na correta seqüência.

Import Queues

A ferramenta mais importante para o mecanismo de import do TMS são as import queues que refletem a situação dos import buffers de um determinado sistema. Ela lista os change requestsdisponíveis para import bem como a ordem com que foram liberados. Os dados exibidos no TMS sãolidos no momento em que a transação é chamada. A opção de refresh permite atualizar asinformações exibidas na tela. O programa RSTMSCOL pode ser schedulado para rodar de hora em hora e efetuar este refresh em background. Isto normalmente é utilizado durante a fase dedesenvolvimento do projeto onde o numero de change requests é muito grande. Durante amanutenção do sistema normalmente não é utilizado pois o número de changes provavelmente serábem menor.

Através da administração da fila de imports é possível excluir change requests, efetuar forwardspara outros sistemas, estabelecer dead lines e end marks, etc. A administração do TMS permite muitaliberdade no tratamento das filas, porém é recomendável que estas manipulações sejam bastanteconscientes para garantir a integridade e consistência dos transportes. A SAP é um pouco mais forte que a vida real, ela recomenda que nenhuma change seja deletada ou manipulada na fila para evitarqualquer tipo de consistência. Para estabelecer end marks nas filas de import é necessário fechar(close) nas filas. Este processo eqüivale a estabelecer stopmarks nos files do sistema operacional (tpsetstopmark <SID>). A diferença básica é que enquanto no sistema operacional é possível acrescentar uma stopmark apenas no final da fila, através do TMS é possível colocar o end markonde for mais conveniente. Este processo é muito útil quando é desejado disparar um import embloco porém até um determinado ponto apenas. O import all (caminhão) efetua o import até encontrara marca postada na fila. Operacionalmente é recomendável que sempre se feche a fila (end mark)antes de iniciar um import, evitando que requests liberados durante o processo também sejamtransportados inadvertidamente.

42

Para evitar inconsistências entre change requests, somente efetue imports de changes isoladosquando, com completa certeza, conhecer o seu conteúdo e sua dos demais requests.Estes imports são denominados Preliminary imports. Como garantia, o TMS mantém os preliminaryimports na fila para que sejam retransportados quando se efetuar o import padrão (all). Em condiçõesespeciais é possível especificar parâmetros diferentes quando do import. São ascomando tp no sistema operacional. Este processo é chamado expert mode. Existem uma série de opções nos expert modes e elas serão detalhadas mas adiante.

Transporting Between Transport Groups

Transporte são gravados nas import queues de um determinado transport group que compartilha omesmo diretório de transporte. A opção In foreign groups (Extras -> Other requests -> In foreigngroups) permite que se efetue transporte entre sistemas que possuem diferentes diretórios detransporte. Esta opção é útil quando o compartilhamento NFS dos sistemas não é permitido poralguma razão técnica (conexão ruim, segurança, compatibilidade, etc.). Neste caso o TMS cuida de sincronizar as informações entre os buffers do grupo de origem e do o grupo de destino.

Transport Monitoring

É possível monitorar o processo de transporte através de uma série de ferramentas do ImportMonitor do TMS. O sistema permite ainda que se verifique a consistência dos arquivos no sistema operacional (Consistency check) e o return code produzido por cada transporte através davisualização da ALOG. O TMS tem ainda ferramentas para testar as funcionalidades do tp program eainda verificar a configuração do diretório de transporte (System check) além do funcionamento dasconexões RFC com os sistemas que compõem o landscape.

Através do Alert Monitor do CCMS é possível integrar algumas funções de monitoração com oTMS permitindo a gerência centralizada do sistema R/3.

Transport Process

O processo de transporte pode ser descrito nos seguintes passos:• O líder do projeto libera o change request após verificar o término das tasks com os

integrantes do grupo de trabalho• O líder verifica ainda se o export foi realizado com sucesso informando ao administrador do

sistema qualquer anormalidade• O administrador importa o change request no sistema de consolidação e garante a execução

correta do processo com return codes aceitaveis.• O time funcional garante os testes exaustivos no ambiente de consolidação. Qualquer

problema detectado deverá ser informado ao líder do projeto para que se inicie a correção e repita o export de uma nova correção para o sistema de consolidação

• O administrador do sistema efetua o import para o ambiente de delivery e demais sistemasconfigurados do conjunto consistente de change requests no landscape e garante a execução correta do processo com a devida verificação dos return codes.

Durante o processo de testes de uma funcionalidade pode ser necessário congelar o trabalho noambiente de desenvolvimento para garantir a estabilidade dos testes. Isto facilita a correção depossíveis problemas encontrados nos objetos, que seria mais difícil de ser corrigido se o processo dedesenvolvimento tivesse continuado no objeto durante os testes.

Uma estratégia periódica para a importação dos transportes deverá ser implementada e negociadacom as equipes de desenvolvimento. Import all deverão ocorrer mensalmente, semanalmente oudiariamente. Imports mais freqüentes não são recomendados no ambiente R/3. O processo de importdeve ser feito durante a baixa atividade do sistema e logo após um backup da base. A SAPrecomenda que o transporte de um projeto seja efetuado apenas quando todos os seus componentesestiverem totalmente desenvolvidos evitando a estratégia de enviar objetos individualmente a medida

43

Advanced Transport Management

Transport Directory

Os change requests são gerados obedecendo a nomenclatura <source SID>K9nnnnn onde nnnnné um seqüencial de 5 dígitos controlado pelo sistema source (também conhecido como sistemaintegrador ou sistema de desenvolvimento e configuração).

O file system do diretório de transporte fica montado na área compartilhada /usr/sap/trans de umadas máquinas (normalmente aquela de onde os transportes se originam) e através de NFS, o filesystem é compartilhado com os demais sistemas que compartilham o mesmo transport group. No ambiente do NT o compartilhamento é feito através do sapmnt que contém, entre outros, o diretório

trans contém os seguintes subdiretórios, entre outros:• actlog, onde são gravados cada action em um request ou task. Contém files com nomes

<source SID>Z<6 digits> • sapnames, com arquivos com o nome do usuário que efetuam release em changes. Com

este arquivo podemos saber exatamente que gerou a request (no sistema operacional)• buffer, com arquivo com nome <SID> contendo o import buffer para cada sistema R/3.

Quando um change request é liberado, o file correspondente ao sistema target é atualizado • data, contendo arquivos do tipo R9<5 digits>.<source SID> que contém os dados que

foram exportados no transporte. Eventualmente neste diretório podemos ter arquivos noformato D9<5 digits>.<source SID> que também contém dados a serem importados.

• cofiles, com command files do tipo K9<5digits>.<source SID> contendo por exemplo osimport steps que serão executados

• log, com todas as logs de transportes, como por exemplo ULOGs, ALOGs, SLOGs e asdemais logs que descrevem as operações executadas nos steps individuais ou coletivos

• bin, com os arquivos de configuração do funcionamento do mecanismo de transportes (TPPARAM e DOMAIN.CFG)

• tmp, com os arquivos de log que estão sendo gerados durante o processo. Após o término de um transporte os arquivos são movimentados para o diretório LOG.

The tp Program

O transport control program é uma ferramenta executada a nível de sistema operacional quecontrola todas as operações de transporte no sistema R/3 usando programas especiais (por exemploem C), comandos de sistema operacional e programas ABAP no R/3. O TP opera as operações deexport e import separadamente, extraindo/atualizando as informações de controle na base de dadosdo R/3 e levando para files (buffer, log e cofiles) no diretório de transporte e posteriormente, atravésde comando explícito, importa os dados no sistema destino. Ele não faz a manipulação dos dadosque serão transportados (o responsável por isso é o R3trans que será visto a seguir).

Apesar de ser uma ferramenta no sistema operacional (diretório de exe’s), o tp deve ser utilizadoatravés da interface do TMS que efetua as chamadas apropriadas para cada tarefa. Sua utilização éuma chamada tp <command> [argumento] [option(s)] como pode ser visto abaixo :

• tp help, exibe o help do tp • tp <command>, exibe o help de um comando específico• tp go <SID>, checa o database de um sistema destino• tp connect <SID>, checa a conexão • tp showinfo <request>, exibe informações de um determinado change request• tp count <SID>, numera os requests para import em um sistema • tp checkimpdp <SID>, exibe como o RDDIMPDP está schedulado em um determinado

sistema • tp showparams <SID>, exibe a parametrização atual de um sistema• tp status <SID>, exibe o status de serialização de um sistema

O comando tp import all <SID> client=nnn executa o import de toda a fila de transporte dosistema <SID> no client nnn. Este é o comando normalmente emitido pelo TMS.

44

O comando tp import <request> <SID> client=nnn u0 executa o import de um request específicoe o mantém na fila, eqüivalendo ao preliminary import do TMS. Quando se suprime a opção u0 orequest é retirado da fila de import. É preciso tomar cuidado com imports individuais para garantir amanutenção da seqüência correta com que os mesmo foram exportados.

O import mode incondicional (com especificação da opção ) tem os seguintes modos:• u0, importa o buffer sem deletar o request da fila• u1, ignora se o request já havia sido importado• u2, sobrescreve os originais• u3, sobrescreve objetos específicos do sistema• u6, sobrescreve objetos em modo unconfirmed• u8, ignora restrições estabelecidas na tabela de classificações• u9, ignora o fato do sistema estar lockado para este tipo de transporte

O buffer de um determinado <SID> é manipulado pelos comandos tp específicos, como porexemplo addtobuffer, showbuffer, delfrombuffer, cleanbuffer, setstopmark e delstopmark. Estescomandos manipulam as linhas do arquivo específico de cada sistema existente no subdiretório buffer

The R3trans Program

O R3trans é a ferramenta de transporte que efetivamente efetua os transportes no sistema R/3,sendo interativamente chamada pelo programa tp ou outros programas no ambiente, como porexemplo o R3up. Efetivamente é o R3trans que vai ler os dados para construir o arquivo K9xxxxx edurante o processo de import vai ler os dados neste arquivo para fazer a atualização dos dados da request em tabelas temporárias no banco de dados do sistema destino. O uso direto do programaR3trans não é suportado e somente utilizado em casos muito especiais. A SAP não suporta ainda ouso do tp ou do R3trans entre releases diferentes do R/3.

The ABAP Programs

Durante os steps de um processo de import de um transporte alguns programas ABAP sãoexecutados no ambiente R/3. O programa RDDIMPDP é um programa schedulado no ambiente paraser disparado pelo evento SAP_TRIGGER_RDDIMPDP. Este evento é disparado no momentocorreto devido ao programa tp através de chamada ao sapevt. Este programa tem que estarschedulado corretamente (baseado no evento) pelo user DDIC no client 000 e em cada client quereceberá transportes para que o import funcione corretamente (é possível verificar isso utilizando ocomando tp checimpdp SID). A execução do programa RDDNEWPP efetua este schedule no sistema,embora o sistema normalmente schedula este job automaticamente após um client copy. Averificação do schedule pode ser efetuada pela SM37. O programa RDDIMPDP se baseia eminformações passadas pelo programa tp para ativar programas RDD* que efetuam tarefas específicasrequisitadas pelo tp. As principais tarefas, a saber, são : mass activation (rddmasgl), convertion andgeneration (rddgendb) e versioning management (rddversl).

The Import Process

O processo de import é composto de uma série de steps que executam tarefas distintas e,dependendo do tipo do transporte, são ativados ou não. A organização da fila de import no buffer fileé uma espécie de tabela onde para cada entrada referente aos requests, é colocado um flag 0 ou 1na posição referente a cada step. O programa tp não lê esta fila individualmente, mas sim coletivamente. Desta forma o processo de import ocorre de forma seqüencial não pelos requests, massim pelos steps. Desta forma o sistema executa o step 1 para todos os requests que o requisitaram,depois o step 2 e assim sucessivamente. Este processo garante por exemplo que caso exista na filade transporte mais de uma referência a um determinado objeto (por exemplo a segunda corrigindo umerro detectado em uma primeira consolidação) o step de ativação (posterior ao de importação) ocorra

45

somente quando a versão correta esteja importada no sistema, evitando desta forma que a versãocom erro seja ativada temporariamente como ocorreria se o processo fosse seqüencial por request.

Para garantir a consistência do tratamento da fila de import, o programa tp colocaautomaticamente um setstopmark na fila no início do processo e a retira no final. Cada operaçãoefetuada durante o processo é logada pelo tp com o respectivo return code nos arquivos de log dosistema de transporte. Ocorrendo erros no processo o programa tp interrompe e após a correção peloadministrador, um restart faz com que o tp encontre o ponto de parada e recomece o processo apartir daquele ponto. Qualquer return code maior que 8 interrompe o programa tp. Este valorentretanto pode ser configurado no arquivo TPPARAM (através do parâmetro stoponerror)

Os passos durante o import são (os passos com * são genéricos e feitos em todas as requests) :• DDIC

• Abap dictionary import• ACTIV

• Abap dictionary activation• Distribution• Structure conversion (*) • Move nametabs (*)

• MAIN • Main import

• MC ACT• Activation of the enqueue definitions

• MC CONV• Enqueue conversion (*)

• ADO• Import of application defined objects ADOs

• LOG• Logical import (esta fase ainda não foi implementada e será utilizada para a importação

em um shadow client antes de fazer em um target client) • VERS

• Versioning• XPRA

• Execution of user defined activities• GENERA

• Generation of abap prograns and screens

Communication During Imports

O programa R3trans, que é chamado durante as fases de ABAP dictionary e main import) se comunica com o programa tp utilizando o subdiretório tmp. Um control file é passado pelo tp para cada step do processo de import e por sua vez o R3trans grava a log do transporte no tmp para que posteriormente seja transferido pelo tp para o subdiretório log. A comunicação entre o programa tp eos jobs background no sistema se dá através da tabela TRBAT que contém dados temporários. O tpgrava nesta tabela os steps que deverão ser executados durante o import e então dispara o eventoque ativa o RDDIMPDP. Este programa por sua vez lê a tabela e através das informações recolhidasdispara programas RDD* que efetuam tarefas específicas requisitadas pelo tp. Cada um dos jobsRDDs disparados pelo RDDIMPDP é registrado na tabela TRJOB através de uma entrada onde sãogravados seus return codes que desta forma podem ser acompanhados pelo programa tp. As logsgeradas pelos programas RDD* são gravadas no subdiretório tmp e posteriormente transferidas parao log pelo programa tp.

Qualquer problema detectado pelo tp durante a monitoração das tabelas TRBAT e TRJOB faz com que o tp reative o RDDIMPDP através da emissão de novo evento pelo sapevt. O RDDIMPDPanalisa estas tabelas e verifica se o processo anterior ainda está ativo ou se necessário,processo no step cancelado. Por este motivo é que pelo menos dois background processprecisam estar disponíveis para o sistema de transporte.

46

Transport Monitoring

Todas as logs do processo de transporte são gravadas no subdiretório de log. São logs criadaspelo tp program (ULOG, SLOGs e ALOG) e pelas demais ferramentas de transporte. A ULOG contémtodos os comandos tp sem erros de sintaxe. Cada linha representa um comando. Existe um arquivoSLOG<YY><WW>.<SID> para cada sistema R/3 do landscape e é usado para monitorar asatividades de transporte de um sistema específico. Contém uma visão geral dos imports efetuadosindicando os respectivos return codes e consequentemente o sucesso de cada import. OALOG<YY><WW> contém todos os return codes de cada um dos steps executados nos processos deimport efetuados no seu transport group.

Além destes arquivos de log, o diretório de logs possui uma log por change request. Estesarquivos possuem o formato <source SID><action>9<5digits>.<target SID> onde o action pode ser :

• E de main export feito pelo R3trans• P de test import feito pelo R3trans • H de dd import objects feito pelo R3trans• A de dd activiation object feito pelo RDDMASGL • S de dd distribution object feito pelo RDDGENBB • N de dd conversion object feito pelo RDDGENBB• 6 de dd move nametabs • I de main import feito pelo R3trans • T de import of table entries feito pelo R3trans• M de enqueue activation feito pelo RDDGENBB• G de repository object generation feito pelo RDDIC03L• V de version update feito pelo RDDIC

As diversas ferramentas envolvidas no transporte envia return codes que são consolidados peloprograma tp da seguinte forma:

• 0 a 16, indica os valores máximos de todos os return codes das ferramentas• 17 a 99, que é um valor calculado a partir daqueles retornados pelas ferramentas de

transporte e são warnings indicando problemas detectados pelo tp, como por exemplo anão permissão de write no diretório buffer

• 100 a 149, são warnings indicando que alguma coisa vai mal e nem todas as tarefas puderam ser completadas

• 150 a 199, são erros (raros de acontecer) indicando uma operação ilegal solicitada pelooperador

• 200 ou mais, indica erros no tp Para obter uma descrição de um return code, utilize o comando tp explainrc <rc>.

Para acompanhar todo o processo verifique as logs dos transportes que foram feitos. As logs detransporte podem ser visualizadas através do Alert Monitor sob a forma de uma estrutura em árvoreque pode sofrer drill down.

O diretório de transporte deve ser limpo de tempos em tempos para eliminar transportes antigos etp check all varre os diretórios de transporte e os

arquivos referentes a transportes já executados são gravados em um arquivo denominado ALL_OLD.LIS no tmp. O comando tp clearold all lê o arquivo gerado pelo comando tp check all e percorre os arquivos referentes as suas entradas e elimina aqueles que aparentemente não serãomais necessários e se tornaram obsoletos baseados em timestamps definidos pelos datalifetime, olddatalifetime, filelifetime e loglifetime do TPPARAM. Antes de efetuar estaoperação é recomendado que se efetue uma cópia backup por segurança.

47

R/3 Upgrades and OCS Patches

R/3 Evolution and Release Strategy

Um sistema R/3 típico, uma vez instalado, passa por evoluções sejam devido a customizações ounovos desenvolvimentos, como também pela aplicação de patches do OCS (Online CorrectonService) ou ainda por upgrade de novos releases.

Novos releases no R/3 podem ser de dois tipos: • Functional Releases, que trazem novas funcionalidades e são enviados para os clientes

apenas sob demanda (3.1G e 4.0A, por exemplo) • Correction Releases, trazem apenas correções e são enviadas automaticamente para

todos os clientes. Estes são os releases recomendados para serem instalados emprodução, já que possuem suporte total do OCS (3.1H ou 4.0B, por exemplo)

R/3 Upgrade

Em um típico landscape de 3 sistemas, cada ambiente (partindo do desenvolvimento) passa poruma seqüência de transportes standard. São tarefas tais como customizações, patches, e ajustes nosistema. Estas alterações são executadas no ambiente de desenvolvimento e transportadas para osdemais ambientes.

Uma das tarefas mais importantes durante a preparação para o upgrade é rodar o script PREPARE (integrante da ferramenta retrofit que integra a localização que existia na versão 3.0 com ocorrespondente standard que vem na versão 4.0) e que é responsável por fazer uma série de checks,a saber :

• Quais são as versões do banco de dados, do sistema operacional, e do R/3• Quais abaps precisão ser realterados• Existe espaço suficiente no banco de dados• Existe alguma reparação em andamento• Quais são as línguas suportadas• Qual é o nível de hot package e se todos estão confirmados • usuário tem as devidas permissões no sistema operacional

Após todo este processo o prepare gera um arquivo chamado \usr\sap\put\log\checks.log) no sistema com as ações necessárias para viabilizar o upgrade. A execução deste script não faz partedo upgrade em si que é feito utilizando o programa R3up que tem funcionamento semelhante ao

Durante o processo de upgrade, são efetuadas alterações de ajuste usando as transações SPDDe SPAU. O processo de upgrade passa por passos que são efetuados com o sistema ativo ainda norelease antigo, a retirada do sistema para que o dicionário seja atualizado e posteriormente maistarefas novamente com o sistema ativo, agora já no novo release.

Antes de fazermos o upgrade do R/3 já temos que ter cumprido alguns passos obvieis como aexecução do script prepare, upgrade do sistema operacional, eventual upgrade do hardware, upgrade do banco de dados e outros fatores que possam ser pré-requisitos para o R/3.

O primeiro passo efetivo do upgrade é a transferência para o repositório do R/3 dos novos objetosenviados em um CD. Este processo passa pela comparação dos objetos para identificar possíveismodifications efetuadas pelo usuário nos objetos SAP standard. Todas as modificações que o clientedesejar manter e cujos objetos SAP no novo release também foram alterados, precisam ser casados com os objetos SAP. Este processo é executado através das transações SPDD e SPAU e éconhecido como Modification Adjustment.

Existem diversos tipos de modification adjustment que são executados antes (através da SPDD) edepois (através da SPAU) da fase do Data Dictionary Activation. Durante esta fase de activation osistema é desativado, que pode durar várias horas. Após esta fase o sistema é reativado já no novorelease.

48

Repository Switch

O coração de um processo de upgrade é o Repository switch. Inicialmente um repositório inteirona nova versão é colocado no sistema e permanece inativo. Este processo requer uma área adicionalem disco que somente será liberada quando o novo repositório for ativado e o antigo deletado.

Para preservar as modifications introduzidas pelo usuário, durante o processo de switch dorepositório as alterações introduzidas pelo usuário são transferidas para o novo repositório através damodificação dos correspondentes objetos SAP do novo release.

A fase de modification adjustment somente será necessário quando o objeto alterado pelo clientetambém foi modificado pela SAP (senão ele será movido integralmente) e quando questionado, o cliente decide continuar com suas alterações por achar que o novo release não incorporadevidamente suas necessidades. Caso o cliente aceite o novo objeto, suas antigas alterações serãodescartadas.

No processo de preparação do repository switch acontecem as seguintes operações:• Transfere para o novo repositório modifications introduzidas pelo cliente cujos objetos SAP

não sofreram mudança no novo release• Salva no version database todas as modifications que foram efetuadas em objetos que

sofreram mudança no novo release. Isto permitirá efetuar os ajustes posteriormente• Copia os objetos que foram gerados através do processo de customizing para o novo

• Transfere para o novo repositório todas as documentações, versões inativas de objetos edesenvolvimentos executados pelo cliente, além dos objetos locais

Uma vez que as operações acima foram efetuadas, o repository switch poderá ser efetuado. Casonão existam objetos que necessitam de adjustment, o switch é uma simples questão de reativar onovo repositório. É simples e rápido, sendo portanto sempre desejável que os objetos SAP permaneçam o mais standard possível.

Switch log during repository upgrade

Durante o processo de upgrade podemos escolher três estratégias diferentes para o uso da log dealteração. Independente de cada uma destas estratégias é evidente que devemos ter backup full off-line de cada ponto do processo para que em caso de pane ou necessidade de retorno a situaçãoanterior tenhamos backup para retornar a situação anterior. As principais fases do upgrade são :

• Inicialização do processo • Importe do repositório • Análise e copia dos novos objetos • Switch, ativação do novo dicionário e ajuste dos objetos impactados • Importe dos dados de controle• Importe da lingua portuguesa • Fase final e backup após todo o processo

As estratégias disponíveis para o upgrade são :• A_OFF: neste caso durante todo o processo não teremos redo log do que foi feito, ou seja,

se precisarmos retornar a um ponto temos que faze-lo no momento do backup full sem apossibilidade de fazer um log-foward. A grande vantagem desta opção é a nãonecessidade de área para o archive. A grande desvantagem é um maior tempo dedowntime acrescido de um backup offline no final do processo.

• A_ON: neste caso manteremos o log do banco ativado. O inconveniente deste mecanismo é o consumo de área de até 6 Gb para a área de archive. A grande vantagem é o menor tempo de downtime e a possibilidade de um backup online.

• A_SWITCH: é uma mescla dos dois processo e a log é desativada no momento do da fasede ativação do novo dicionário. O consumo de disco é menor que na opção A_ON maisainda é considerável. O downtime também é pequeno mas é seguido de um backup offline.

49

Ou seja, ela possui um pouca do lado bom das outras duas e é por isto que esta opção é arecomendada pela SAP e já é o default.

Modification Adjustment

O processo de modification adjustment consiste na transferência para os novos objetos SAPdas modifications introduzidas pelo usuário no release anterior.

SPDD é utilizada para efetuar esta transferência em certos objetos doABAP, tais como domains, data elements, table structures, transparent tables, pooled tables, clustertables e table technical settings. A não execução desta tarefa causaria a perda de dados

Após a ativação do novo dicionário, a transação SPAU é utilizada para ajustar alguns objetos quese não ajustados não causariam perda de dados, apenas perda de funcionalidade. Estes objetosseriam objetos de lock, matchcodes e views, além de objetos do repositório, tais como ABAPprograms, function modules, menus, screens ou module pools

Ao término da execução destas duas tasks (SPDD e SPAU), todas as modifications estarãoincorporadas no novo release. No release 4.0 o processo de pre-upgrade PREPARE (scriptmencionado anteriormente e integranda retrofit tool) para o upgrade efetua um check geral dosistema e lista todos os objetos que sofreram modifications e consequentemente necessitarão de passar pelas SPDD e SPAU, podendo desta forma haver um melhor planejamento do esforço aser gasto no processo.

O processo de modification adjustment executa um comparação entre as duas versões do objeto. Para cada objeto, as transações SPDD e SPAU guiam o usuário através dos processos de ajuste,oferecendo ainda a opção de aceitar a nova versão ou executar os ajustes necessários. Estesajustes, quando efetuados, serão salvos em change requests (um para a SPDD e outro para a SPAU) permitindo que o processo de upgrade nos demais sistemas possam ser efetuados de forma maissimples pela aplicação destes transports.

Este procedimento de transporte é simples e poupa esforços de efetuar os adjustments em cada somente é possível apenas se todos os sistemas do ambiente estiverem nos

no momento dos upgrades. Um landscape bem planejado e bem gerenciado torna este processo viável e diminui sensivelmente os esforços no upgrade.

Em relação as responsabilidades do processo de upgrade, temos que ter em mente que osadministradores do sistema são responsáveis pelo upgrade mas os times funcionais e de abap sãoresponsáveis pelos ajustes e testes das funcionalidades que serão afetadas pelo upgrade.

Avoiding Modifications in R/3 Systems

Para simplificar os processos de upgrade (minimizando ou até mesmo eliminando a necessidadede efetuar modification adjustments), a SAP recomenda que se evite modifications tanto quantopossível. Além de demandarem mais esforços durante upgrades, estas alterações no standard coredo R/3 podem introduzir erros graves no ambiente R/3. Dependendo do nível destas modificações eseus reflexos no negócio da empresa, um processo de upgrade poderá ser difícil, demorado ou atémesmo impossível de ser implementado em versões mais recentes do R/3.

Em substituição às modifications, a SAP disponibiliza o conceito de enhancements, através dauser exits e appended structures que tornam o processo de upgrade totalmente

transparente para a instalação

O conceito de user exits consiste na introdução em determinados pontos mais susceptíveis amodifications dos objetos SAP de chamadas a rotinas externas que podem ser desenvolvidas pelocliente em sua instalação. Novos releases trarão estas chamadas nos mesmos pontos nãonecessitando o cliente de efetuar nenhuma alteração no novo objeto. Os objetos que possuem exit

• Programas exits, que permitem includes no código através de chamadas externas

50

• Menu exits, podendo o cliente introduzir novas opções no menu• Screen exits, que são telas adicionais • Field exits, que são programas ou function modules conectados a um campo de tela para

executar funções por exemplo de consistência personalizada de preenchimento. Aocontrário dos demais tipos de exits, field exits não precisam ser criadas para umdeterminado campo, podendo o cliente decidir pela sua colocação em qualquer campo.

As append structures permite que se acrescente campos em tabelas SAP sem a necessidade dealteração dos objetos standard do sistema. Os campos incluídos ocupam fisicamente uma outra áreae apenas serão incorporados a nova versão do objeto no novo release. Estas estruturas deverão possuir nomes no customer range (Z) para evitar que sejam sobrescritas no momento do upgrade. Ainclusão destas estruturas entretando não são permitidas a pool tables, cluster tables ou tables quepossuam campos LONG RAW.

Online Correction Service (OCS)

O OCS oferece patches para correção de um sistema R/3 através da disponibilização de HotPackages, LCPs, SPAM updates e Conflit Resolution Transport (CRTs). Estes patches reduzem anecessidade de correções manuais no sistema através da aplicação de notas que, diferentementedestas correções, não serão reconhecidas por um processo de upgrade como modifications. É portanto extremamente aconselhável que um sistema R/3 esteja up to date no momento de um upgrade para minimizar a necessidade de análise de modifications que não passam de notasaplicadas.

Os tipos de patches na versão 4.0 são :• Hot Packages são grupos de vários patches e devem ser aplicados na ordem em que são

disponibilizados pela SAP. Tecnicamente durante a sua aplicação requerem modificationadjustments através da transação SPAU.

• LCPs ou Legal Change Patches, são os Hot Packages para o ambiente HR • SPAM update é uma atualização para a transação SPAM (utilizada durante a aplicação

dos Hot Packages)• CRTs ou Conflit Resolution Transports suprem objetos adaptados para resolver conflitos

entre o R/3 e alguns SAP add-onsEstes patches ficam disponíveis para download no sapnet (ou através de download via OSS a

partir da SPAM). Para simplificar a sua implementação, a SAP empacota umas 3 vezes ao ano os HotPackages, SPAM updates e LCPs em um CD que é enviado para o cliente.

O SAP Patch Manager (transação SPAM) é a ferramenta utilizada para aplicar os patches no ambiente R/3 e deverá ser executada no client 000 por um usuário que possua todos os privilégios(SAP_ALL) porém não deverá ser o DDIC ou o SAP*. A SPAM força a aplicação dos patches naordem correta e obriga a um aceite em cada aplicação antes de aceitar a seguinte, forçando destaforma a uma verificação da aplicação pelo cliente. O processo de aplicação dos patches deve serefetuado em todos os sistemas do landscape. Caso se efetuem adjustments pela SPAU durante aaplicação, os mesmos poderão ser salvos em change requests para posterior import nos demaissistemas, evitando a utilização da SPAU mais de uma vez.

Ao longo da utilização e conseqüente identificação de problemas nas funcionalidades do sistema,pode ser necessário aplicar manualmente no R/3 correções disponibilizadas em notas no OSS. Estasnotas (porém nem todas) serão posteriormente agrupadas em Hot Packages. Qualquer nota deverá

51

R/3 Spool and Print

As definições de impressora são client independents, ou seja, basta definir a impressora em umdos mandantes para que todos possam utiliza-la. De preferencia aos clients mais nobres de cada umdos sistemas R/3. As principais transações deste capítulo são SP01 e SPAD.

R/3 Spool System

O R/3 possui diferentes formas de enviar documentos através de seus sistemas de spool. Umdocumento formatado, que pode ser uma impressão, um fax ou um EDI, representa uma message no sistema R/3 e, uma vez criada, estará liberada para impressão ou transmissão. As impressões noR/3 podem ser imediatas ou adiadas para saída posterior. Além do message control, o R/3 possuiuma combinação de programas de impressão e SAPScripts para produzir os documentos deimpressão. Enquanto o programa de impressão obtém os dados a serem impressos, o SAPscriptsespecifica o layout do documento a ser impresso.

Como o sistema R/3 é um ambiente multiplataforma, foi criado um sistema interno de spool parainterfacear com os diversos hosts nos quais o R/3 pode rodar. Através deste princípio o R/3 formataos documentos e requisita ao spool do sistema operacional que apenas repassa o documento para odispositivo físico de impressão que está alocado na porta paralela ou serial.

Spool and Output Requests

Um spool request é criado quando um documento R/3 é requisitado para impressão mas aindanão foi enviado para o dispositivo de saída. Os dados ficam armazenados em uminterno do R/3. Um spool request é formatado pelo spool work process e passa a ter um determinadoformato para um dispositivo específico, este formato nos chamamos de output request. Vários outputrequests podem ser gerados a partir de um único spool request, contendo cada um os atributos ou comandos específicos de um determinado hardware de impressão.

Os spool requests gerados ficam armazenados em um repositório denominado TemporarySequential Database, ou TemSe. Este repositório poderá estar no banco de dados do R/3 ou em arquivos do global directory do sistema operacional (determinado pelo parâmetro de profilerspo/store_location = db ou G e direcionado pelo parâmetro rspo/files/root/G = $(DIR_GLOBAL) ). Osoutput requests são armazenados apenas como registros de controle. Os formatos de impressão umavez gerados são repassados diretamente para o gerenciador de impressão do sistema operacionalsem serem armazenados na base de dados.

Spool Work Process

Quando uma requisição de impressão de um spool request é efetuada, um output requestespecífico para o device desejado é criado pelo spool work process do R/3, que lê os dados a serem impressos no TemSe (spool request) e o formata baseado no driver do dispositivo especificado. Umavez formatado, o dado é repassado diretamente para o spool do sistema operacional para que oencaminhe para o dispositivo endereçado. Para formatar corretamente a saída, além do driver específico do dispositivo o R/3 utiliza informações referentes ao character set utilizado e comandosespecíficos do dispositivo para formatação dos dados.

Local and Remote Printing

Os output requests formatados são repassados para os dispositivos através de strings deimpressão. Quando se utiliza o método Local, os dados são repassados diretamente para o spooler

52

do sistema operacional da máquina onde o spool work process que cuida de envia-los, seja para umaimpressora conectada diretamente ao host ou através da rede. É o método mais rápido, uma vez que a tarefa de gerenciamento do string até o dispositivo de saída fica a cargo do sistema operacional,liberando o work process desta tarefa. Evite utilizar o host onde o sistema R/3 está rodando como ohost que controla esta fila de impressão e possui uma impressora ligada fisicamente pois isto vaiconsumir recurso do sistema operacional. Existem cinco métodos de acessos, a saber :

• L, utilizado onde o output request é passado para o gerenciador de impressão do sistemaoperacional (do tipo line command). O mais comum é ser utilizado no ambiente unix mas também pode ser utilizado no ambiente Windows NT. Os comandos a serem utilizados paraimprimir e para verificar a fila podem ser redefinidos através dos parametrosrspo/host_spool/print e rspo/host_spool/query, respectivamente

• C, utilizado onde o output request é passado para o gerenciador através de call a bibliotecas específicas do sistema operacional. Deve ser utilizado com Windows NT e AS/400

• E, utilizado para enviar o output request para um OMS (será detalhado logo a seguir)• P, utilizado para enviar o output request para um device pool• F, utilizado para impressão no front-end e quem formata o output device é o dialog work

process

Remote printing consiste na transferência dos output requests diretamente para os dispositivosremotos. Neste caso o spool work process fica responsável pela negociação com o dispositivoatravés da rede. Este método de acesso remoto é menos otimizado por onerar o work processgerando possíveis contenções na impressão. O spool work process fica preso até que ele consigapassar todas as informações para o spooler remoto (ou saplpd) que eventualmente fica esperando obuffer da impressora, ou seja, o spool work process fica preso até que a maior parte da impressãofísica seja feita. A transmissão remota é feita através de lpd (line printer daemon) e a SAP provê oprograma SAPLPD para as plataformas que não possuem este protocolo standard. Devemos utilizareste método somente quando a rede for muito rápida e muito confiável. Os métodos de acesso são :

• U para os ambientes baseados no unix e impressoras de rede• S para ambientes windows 9x com saplpd

Spool Administration

A transação SPAD é utilizada no R/3 para a administração de spool. As impressoras (outputdevices) são definidas especificando o método de acesso (local – L ou C - ou remoto – U ou S paraunix e windows respectivamente ) e suas características (device type, spool server, print server,atributos documentacionais, etc.). Para impressora remota devemos sempre utilizar o nome do printserver no formato UNC //<host_name>/<printer_share_name>. Na versão básica da SPAD podemos definir output devices, spool servers, access methods e destination hosts. Podemos também verificara instalação, deletar spools antigos, verificar a TemSe e acionar SP01.

Frontend Printing

A impressão frontend no R/3 permite que usuários enviem output requests para impressoras quenão foram definidas como output devices no R/3. É o denominado método de acesso F. Caso aestação do usuário seja um PC windows, o request é enviado para um SAPLPD rodando na estaçãodo usuários. Se o SAPLPD não estiver rodando, ele é iniciado e manipula os requests e os envia para

Neste método de acesso o processamento do spool é efetuado pelospróprios dialog work processes, não havendo necessidade de encaminhar o request para os spoolwork processes. Para definir uma impressora frontend para as estações windows, além de especificaro método de acesso F, é necessário definir o device type SWIN (qualquer impressora com device instalado no windows) e o host printer deverá ser “__DEFAULT”. Este método deverá ser evitado emsistemas produtivos por utilizar os work processes para tarefas que deveriam estar reservadas paraos spool work processes além de prender o dialog work process até que todos os dados daimpressão sejam passados para a estação onde está o frontend e o saplpd.

53

Logical Spool Servers

Logical spool server é uma camada que permite mapear spools lógicos para físicos, permitindoefetuar o switch dinâmico e balanceamento dos servidores. Um real spool server no ambiente R/3 éuma instância com pelo menos um spool work processes definido. Este mecanismo de definição lógica permite efetuar o switch facilmente entre servers reais que estão indisponíveis sem interrupçãodo serviço de impressão para os usuários. Como estas definições são configurações do ambiente eportanto podemos utilizar o mecanismo de transportes de change requests do R/3 é possível definirtoda uma arquitetura de impressão em um ambiente e posteriormente transporta-la para os demaissistemas do landscape.

Spool Request Management

O spool requests gerados no sistema devem ser gerenciados pelo administrador para garantir adisponibilidade do ambiente. O programa RSPO0041 deve ser schedulado em todos os sistemas paraefetuar o trabalho de housekeeping e eliminar spools antigos do sistema.

A transação SP01 é o spool request viewer, que permite aos usuários ver seus requests erequisitar outputs ou eliminar spools. Administradores com autorizações apropriadas podem ver todo

SPAD ou o programa RSPO0043 pode ser utilizado para checar a consistência entre os spool requests, output requests e output datas são consistentes cadaum por si e as referencias cruzadas entre eles. A verificação de problemas associados com os spoolrequests pode ser efetuada tanto pela SP01 quanto pela SM21 ou ST22.

Existem objetos de autorização específicos para diversas operações de spool no R/3, sejaprotegendo determinados dispositivos de saída (S_SPO_DEV) ou limitando o poder degerenciamento (S_SPO_ACT e S_ADMI_FCD) . O objeto S_SPO_PAGE limita o número máximo depáginas que um usuário pode imprimir em um determinado dispositivo. Para que esta autorizaçãotenha efeito é necessário ativar o parâmetro de profile rspo/auth/pagelimit=1.

54

R/3 Output Management

Através da opção de administração estendida na SPAD, uma série de funções avançadas podemser escolhidas tais como : definição de device types, print controls, formats, page formats, OMS echaracter set.

Device Pools

O conceito de device pools é permitir que se defina um pool de dispositivos de saída que podemser referenciados através de um único nome. Device pools são definidos especificando método deacesso P e a lista dos dispositivos que o compõem. Output requests podem ser enviados para todosos dispositivos que compõem o pool simultaneamente ou pode-se requisitar que o sistema efetue obalanceamento de carga entre os dispositivos de saída da lista. Os dispositivos que compõem a listade um device pool podem ainda ser acessados individualmente como devices independentes.

Para o caso de utilizarmos o balanceamento de carga temos que ter certeza que a rede e ogerenciador de impressão do sistema operacional tem bom tempo de resposta pois para balancear acarga o R/3 vai fazer query para saber o status do device.

External Output Management Systems (OMS)

O R/3 permite integrar ao seu ambiente sistemas externos de gerencia de impressão que podemse fazer necessários em ambientes complexos. Esta comunicação é efetuada através do XOM-API.Através da definição de um objeto real de OMS (ROMS) e de pelo menos um objeto lógico OMS(LOMS), os spool requests de um sistema R/3 podem ser passados para o sistema externo. Osdevices no ambiente R/3 que serão gerenciados pelo sistema externo OMS são definidos com o

Spool Server and Requests Management

Qualquer instância R/3 que possui spool work processes é denominada um spool server. O R/3permite a definição de um alternate spool server que pode assumir as tarefas de um spool serverprincipal. Quando se assinala o campo non-exclusive spool server no atributo de um spool server o sistema R/3 efetua o balanceamento de carga dos requests de impressão.

O sistema R/3 permite que se classifique os servidores e os dispositivos em categorias (Highvolume, Production, Desktop e Test) o que faz com que o sistema envie uma mensagem de warningquando se efetua o assign de um determinado dispositivo com um server incompatível. Os requestsenviados para um determinado spool server caem em uma fila de spool e são processadossequencialmente. Quando o server possui mais de um spool work process, os requests sãomanipulados paralelamente de forma que determinado request da fila poderá ser enviado para umdispositivo antes de outro documento pesado que ainda esteja sendo formatado. Caso se defina umdispositivo com a opção de sequential request procesing, os output request para o dispositivosserão serializados. Esta definição pode causar impacto em todo o sistema de impressão, já quedurante a presença de requests para o device, um determinado spool work process fica reservadopara processar a fila do device que possui a característica de processar os requestssequencialmente.

Para permitir que os usuários acompanhem o andamento de seus requests, os spool work processquestionam os devices sobre o sucesso das operações. Uma vez que durante este tracking o spoolpermanece aguardando uma resposta, isto pode ser particularmente problemático paraimpressoras remotas ou com baixa performance na rede. Esta opção pode ser desabilitada para um dispositivo de saída especificando a opção no longer ask for print requests in host spool.

Ao se especificar o atributo monitoring using monitoring infrastructure, o device pode ser monitorado atrvés da árvore de MTEs do CCMS. Além das opções da jenela de manutenção dodevice temos ainda os parametros para controle de time-out e retries (rspo/tcp*).

55

Non-Standard Printers

Quando um determinado dispositivo de saída não possui device padrão no R/3, é possível criarum driver personalizado para o dispositivo através da especificação de alguns objetos. A transaçãoSPAD, em extended admin, fornece todos os mecanismos para formatar e testar o drive a serutilizado pelo novo dispositivo. Antes de definir um novo dispositivo, verifique no OSS se já não existedisponível o novo driver para ser baixado do sapservX. Se for necessário criar realmente um novodriver cópie um já existente e altere o que for necessário, sempre tentando manter o mais próximo do

Character set

O character set especifica os códigos internos armazenados no spool request e seus respectivosASCII que serão impressos. É um de para. Cada caracter tem um código interno no R/3 (nenhuma relação com o ASCII), cuja lista pode ser visualizada através da SPAD (Full Administration � SAPcharacters). É possível acrescentar caracteres nesta lista, utilizando os códigos 9000 a 9999.

Cada tabela de character set disponível transcreve este código interno R/3 para um determinadoASCII. Para adapter uma determinada tabela, é necessário inicialmente copia-la e então efetuar asalterações na cópia e salvando posteriormente as alterações em um character set identificado por

Format, Page format e Format actions

Format identifica o papel utilizado pelo R/3 (letter, A4, etc.). Quando utilizamos formulários quenão são padrões é necessário definir novos formatos pela SPAD. Os Page formats provê a interface entre o format e o SAPscripts, permitindo que os programas R/3 possam determinar o número delinhas por página, entre outros dados. Para definir format actions, ou seja, como determinadodispositivo manipula um determinado formato de impressão, é necessário editar o dispositivo de saídae acrescentar na sua opção de format as sequencias de caracteres para efetuar as operações deimpressão (printer initialization, new line, skip page, 12 char/inch, etc.)

Print controls

Os print controls determinam como um determinado dispositivo efetua determinadas operações,como por exemplo imprimir em bold. Print controls são específicos de cada device e durante a formatação são convertidos para determinadas sequencias de caracteres. A sequencia correta deveser obtida no manual da impressora, após ter certeza que a SAP não disponibilizou driver para estedevice.

Message Control and EDI

O message control é utilizado no R/3 para troca de informações entre parceiros envolvidos emuma determinada regra de negócio. Os documentos gerados (EDI, fax, impressões, etc.) sãonormalmente gerados através de exits específicas dentro programas R/3 que são chamadas para formatar a saída desejada. Dependendo da customização efetuada, o documento gerado é enviadocomo parte da transação ou fica pendente para posterior envio. O EDI, Electronic Data Interchange, éa troca de mensagens de negócio entre dois sistemas através de interfaces standard. A SAP nãofornece um subsistema EDI no R/3, mas provê uma interface aberta para estes sistemas seconectarem. Esta interface é baseada em Intermediate Documents, ou IDOCs. No R/3 todos os dadostransferidos por EDI são transferidos através de RFCs entre os sistemas envolvidos.

56

SAPconnect

O SAPconnect é uma camada que permite a comunicação do R/3 com outros sistemas externos,tipo fax ou mail servers. A conexão do R/3 com sistemas externos normalmente requer aespecificação de interfaces externas, porém a conexão entre dois sistemas R/3 via SAPconnect podeser feita diretamente. Estes adapters externos devem ser fornecidos por cada fornecedor interessadoem se conectar com o sistema R/3. A SAP fornece um adapter para o Microsoft Exchange Server quepode ser configurado para integrar as duas ferramentas. Para configurar o SapConnect utilize a transação SC0T. Para maiores informações sobre o SapConnect utilize as notas 34705 e 92950.

57

Database Fundamentals

Oracle Overview

Uma instância oracle é o conjunto volátil de processos e estruturas de memória. Um banco dedados oracle é um conjunto de arquivos de dados que são manipulados pela instância oracle.Podemos dividir o Oracle em uma série de estruturas de memória. A mais famosa entre elas é a SGA(system global area) e ela é um grande grupo de buffers de memória compartilhados, a saber : sharedpool, database buffer cache e redo log buffer. Para acessar estas estruturas existem os processosque executam uma série de tarefas de manutenção da instância. Cada processo é distinto, possuiuma função específica, é executado em background e assincronamente. Os principais processos são: pmon, smon, dbwr, lgwr, reco, lck ckpt, snp e arch.

A shared pool é uma porção de memória compatilhada que contém as áreas chamadas de sharedsql, library cache, data dictionary cache e sequence cache. Todas participam do processo e são as estruturas que contém os sqls que estão sendo execudados pelos múltiplos usuários. Essas áreascontém ainda os comandos na forma interpretada e texto, a análise dos comandos com osrespectivos planos de execução, informações de dicionários e geradores de números sequenciais. Oprincipal objetivo da shared pool é viabilizar que um comando sql seja utilizado por diversosprocessos distintos. Uma única shared sql area pode ser compartilhada por diversas aplicações queusam o mesmo comando deixando mais áreas em memória disponível para os outros usuários emelhorando a performance de execução de um comando, já que o plano de execução estará definido

58

O database buffer cache é organizado em duas listas: a lista de blocos alterados e a lista dos

blocos menos recentemente utilizados (LRU – least recently used). Essa segunda lista contém osblocos livres, aqueles que estão em uso e inclusive blocos alterados. Quando um processo servidorprecisa ler dados de um bloco do disco para o database buffer cache, ele pesquisa a LRU para localizar o bloco livre. Se encontrar um bloco alterado, movimenta-o para a lista de blocos alterados.Esse processo termina quando um bloco livre é localizado ou quando um número específico deblocos são pesquisados sem encontrar um bloco livre.

O redo log buffer armazena todas as alterações feitas em um banco de dados em memória. Todasas entradas de redo log neste buffer são escritas nos arquivos de redo log, que são usados para a

O Oracle cria um conjunto de processos que rodam em background para cada instância, Essesprocessos executam diversas tarefas. Entre eles podemos destacar :

• DBWR – O processo database writer escreve os blocos modificáveis do database buffer cachepara os arquivos de dados. Os dados mais antigos são escritos em primeiro lugar. O dbwr adiaao máximo a escrita dos blocos alterados para otimização de I/O em disco para evitar aquelaque é uma das principais causas de queda de performance de um banco de dados.

• LGWR – O processo log writer escreve todas as entradas de redo log para o disco. Os dados de redo log são armazenados em memória no redo log buffer, e no momento em que umatransação for efetivada ou o redo log estiver com preenchimento de pelo menos um terço, olgwr escreve as entradas de redo log para os arquivos online redo log files.

• CKPT – O processo de check point envia um sinal para o dbwr no momento do check point.Ele então atualiza os headers dos control files e dos datafiles.

• SMON – O processo de system monitoring efetua a recuperação da instância em caso defalhas, durante a uma inicialização. Ele também limpa os segmentos temporários que nãoestão sendo usados, liberando memória e recupera qualquer transação pendente no caso deuma falha física. Simplificando, o smon é um monitor das ações do sistema detectando ecorrigindo possíveis falhas no sistema

• PMON – O processo monitor executa a recuperação do processo de um usuário em caso defalhas. Ele limpa a área de memória e libera os recursos que o processo usuário estavausando. Simplificando, o pmon é um monitor das ações dos usuários detectando e corrigindopossíveis falhas nos processos dos usuários

• ARCH – O processo de archiver copia os arquivos redo log para fita ou mesmo outro disco, nomomento em que um deles torna-se completo. Este processo geralmente está presentequando o banco de dados esta sendo utilizado no modo archivelog.

• RECO – O processo de recover é usado para resolver transações distribuidas e pendentes.• LCKn – Os processos de lock (lckn) são usuados para controlar o lock entre instâncias em

uma configuração oracle parallel server.

Dentro de uma instância Oracle existem vários processos que são criados quando a instânciaentra em funcionamento. Eles se dividem em dois grupos :

• Dedicated shadow processes: que são os processos criados no Oracle para as conexõesdos work processes. Existe uma relação de 1 para 1 entre estes processos e os workprocesses da instância R/3 e eles só aparecem quando o R/3 está no ar

• Shared processes: são os processos criados no Oracle para gerenciamento e funcionamentoda instância que irá controlar o banco de dados. Eles tem atividades especificas e trabalhampara a manutenção da instância como um todo.

Os dados são armazenados em datafiles organizados em blocos de 8k (8192 bytes). Estes blocossão carregados para uma área comum da memória principal denominada database buffer pool.Sempre que uma leitura é feita pelo menos dois blocos são carregados, um para header e outro para dados. Cada bloco do DB buffer pool contém um header com os dados das transações que poderãocompartilhar o mesmo bloco. O número de entradas no header é configurado pelo parâmetroINIT<SID> do .ora.

As alterações efetuadas nos dados do banco de dados são feitas inicialmente no database buffer com a imagem anterior copiada para a área de rollback e refletidas na redo log files garantindo comisso a segurança transacional dos dados. Estes redo log files são espelhados por questões de segurança. Os control files não são espelhados mas deve possuir mais de uma cópia, também pormotivos de segurança. Para verificar quantos control files existe utilizem a view v$controlfile através

59

de sql ou da ST04. Para criar mais uma cópia do control file, copie o arquivo para o local desejado ealtere o parametro control_file no initSID.ora acrescentando o novo caminho, tudo isto com o oracleno estado NoMounted. Se for necessário acessar o controlfile com o banco for a do ar o estado dobanco deve ser Mounted.

Os comandos SQL executáveis ficam armazenados em outra área da memória denominadaShared SQL area que também é parte do shared pool. Nesta área temos ainda Library cache com oscursores de execução dos comandos SQL e a Row cache, com informações dos objetos no dicionárioOracle.

Os work processes do R/3 se conectam com os shadow processes no Oracle com o usuárioSAPR3. Caso esta conexão caia, os work processes tentam reconexão com o Oracle seguindo aparametrização feita nas profiles (default ou instance) através das variáveis rsdb/reco_trials ersdb/reco_sleep_time. Uma instância Oracle aceita 3 tipos de conexões de seus clients: dedicated,que é a utilizada pelo R/3, Combined e Multi-thread.

Os principais problemas de performance estão associados a shared pool (shared sql area e rowcache), ao uso dos data buffers e a redo log. Outro ponto de preocupação é o acesso a disco, suaestruturação de alocação e a possível contenção causada pelo acesso ao disco.

Obs: Conceito Importante - O check point é uma marca de sincronismo entre todos os datafiles ea online redo logfiles. Sempre que ocorrer um switch no online redo logfiles é gravado um check pointpara garantir a segurança e sincronismo. Se o banco estiver em archivelog mode, a offline redo logfileé archivada no diretório saparch logo após o switch.

Starting and Stoping the Database

O banco de dados Oracle passa por três fases distintas ao ser inicializado:• Nomount phase: a instância Oracle é construída (shared pool) a partir das informações

parametrizadas no arquivo init<SID>.ora• Mount phase: o control file é aberto e suas informações referentes aos logs e datafiles são

obtidas mas não podemos acessar os datafiles através de um sql.• Open phase: todos os files são abertos. Se o último shutdown não foi realizado com sucesso,

o sistema efetua um rollback das transações inflight e retorna todos os arquivos ao ultimoponto de sincronismo (check point). Os processos podem então começar a submeter requestsao banco de dados aberto.

O shutdown pode ser realizado em três formas distintas também, a critétio do administrador:• Shutdown Normal: O sistema para de aceitar novas conexões e após o encerramento de

todas as conexões já efetuadas os datafiles são fechados, o database desmontado e ainstância finalmente sai (shutdown)

• Shutdown Immediate: Apenas os comandos já em andamento são terminados. Todas asconexões são derrubadas através do PMON e caso exista alguma transação inflight, é feitoum rollback antes da instância sair através de um shutdown consistente, ou seja, um checkpoint é gravado. No sapdba ainda temos shutdown immediate force que retira o R/3 antes dederubar o oracle.

• Shutdown Abort: Em casos de emergência apenas, este comando derruba todas asconexões e retira a instância do ar colocando o banco de dados em um estado deinconsistencia. O próximo startup precisará efetuar um recovery das transições quepermanecerão inflight, até que a base volte a ser consistente (roll foward)

Oracle Shared Processes

Uma instância Oracle possui três processos cuja finalidade é gravar os dados da SGA (shared global area) para os datafiles

• Database writer (DBWR): que assincronamente grava os blocos alterados do data buffer paraos database data files.

• Checkpoint process (CKPT): que acelera o processo de gravação dos checkpoints na

60

• Logwriter (LGWR): que grava em modo síncrono as alterações efetuadas nos data buffer elogadas na redo log buffer para os online redo log files

Um banco de dados em produção deve sempre rodar em ARCHIVELOG mode. Neste caso um quarto processo, o archive (ARCH), grava os online redo log files para a área de archive da instância.Os arquivos do online redo log files funcionam de forma cíclica e a cada switch, o file que estavasendo usado é transferido para a área de archive. O parâmetro da init<SID>.ora,log_archive_start=TRUE ativa o processo de archive na instância. O processo ARCH se baseia nosparâmetros log_archive_dest (default $ORACLE_HOME/saparch) e log_archive_format para gerar oarchive na offline redo log area. Quando o online redo log file foi transferido com sucesso, orespectivo file fica disponível para ser sobrescrito no processo cíclico de utilização dos files.

Caso não haja espaço disponível na offline redo log area para a gravação do novo file, o onlineredo log file não é liberado e consequentemente irá travar a instância quando o ciclo requisitar novamente o online redo log file, devendo a área ser liberada para que o Oracle continua com o seufuncionamento normal.

R/3 Oracle Structure

A estrutura de tablespaces do R/3 no Oracle obedece a um padrão específico de nomes:PSAP<name>[D para data e I para index]. Por exemplo, se uma área de dicionário do R/3 ficaráarmazenada nos tablespaces PSAPDDICD (dados) e PSAPDDIC (índices). Esta nomenclatura éobrigatória para o uso do R/3 e suas ferramentas.

As tablespaces que normalmente são criadas nas instalações são : Prefix Tablespace Ext. Meaning Owner

SYSTEM Oracle DDIC Oracle rdbms

PSAP ROLL D ou I Segmentos de rollback Oracle rdbms PSAP TEMP D ou I Area temporaria normalmente utilizada para sort Oracle rdbms PSAP EL<release> D ou I Módulos do ambiente de desenvolvimento Basis PSAP ES<release> D ou I Fontes do ambiente de desenvolvimento Basis PSAP LOAD D ou I Módulos das janelas e relatórios Basis PSAP SOURCE D ou I Fontes das janelas e relatórios Basis PSAP DDIC D ou I Dicionário abap Basis PSAP PROT D ou I Tabelas do tipo log Aplicações PSAP CLU D ou I Tabelas cluster Aplicações PSAP POOL D ou I Tabelas pool Aplicações PSAP STAB D ou I Tabelas de dados mestres ou transparentes Aplicações PSAP BTAB D ou I Tabelas de dados transacionais ou transparente Aplicações PSAP DOCU D ou I Documentações, sapscripts e sapfind PSAP USER1 D ou I Tabelas do cliente Aplicações

Os datafiles que compõem o tablespace também deverão possuir uma estrutura própria de$ORACLE_HOME / sapdatan / <name>[d/i]_n / <name>[d/i].datan. O sapdatan

normalmente é um mount point (sapdata1, sapdata2, etc.). Caso o tablespace do exemplo acimativesse dois datafiles e alocado no sapdata5, os arquivos teriam o seguinte nome: /oracle/<SID>/sapdata5/ddicd_1/ddicd.data1 e .../ddicd_2/ddicd.data2. Os data files de índicesobedeceriam o mesmo critério, apenas o nome seria ddici, e não ddicd (.../ddici_1/ddici.data1)

Todos os objetos alocados nos tablespaces PSAP... pertencem ao usuário SAPR3. Ostablespaces SYSTEM, PSAPROLL e PSAPTEMP possuem objetos que pertencem aos usuários SYSou ao SYSTEM. O usuários que se logam em um sistema R/3 não possuem objetos nas tabelas doOracle, apenas armazenam linhas nas tabelas do banco de dados através da conexão efetuada como user SAPR3

A estrutura de diretório do Oracle com o R/3 obedece a seguinte hierarquia :• /orant (oracle home)

61

• database: contendo as profiles utilizadas pelo Oracle e pelo SAP (init<SID>.ora,init<SID>.sap, etc.).

• bin: executáveis Oracle (no NT ele está no /orant/bin)• /net80/admin: arquivos de configuração do NET8

• /oracle/<SID> (sapdata home) • sapdata1,2,...: onde se localizam os data files • origlogA, origlogB: online redo log files• mirrlogA, mirrlogB: mirror online redo log files • saptrace/background: Oracle alert files • saptrace/usertrace: trace files dos shadow oracle processes• sapereorg: área de trabalho para reorganizações, compress de backup files, etc. • saparch: offline redo log area e logs do BRARCHIVE• sapbackup: BRBACKUP e BRRESTORE logs• sapcheck: sapdba logs (-next, -check, -analyze)

Dentro do database, existem basicamente três arquivos de parametrização:• init<SID>.ora: parametrizações da instância Oracle • init<SID>.dba: parametrização do sapdba• init<SID>.sap: parametrização das ferramentas BRBACKUP e BRARCHIVE

Várias variáveis de ambiente parametrizam o usuário <sid>adm :• ORACLE_SID=<SID>: nome da instância• DBS_ORA_TNSNAME: seta o <SID> do banco que será conectado através do

tnsnames.ora• ORACLE_HOME: o diretório home do oracle (/oracle/<SID>)• SAPDATA_HOME e SAPDATAn: aponta para diretórios específicos contendo dados

Além dos usuários Oracle SYS e SYSTEM, existem os seguintes usuários no unix :• ora<sid>: usuário unix pertencente aos grupos dba e oper • <sid>adm: usuário unix pertencente ao grupo oper• OPS$<sid>adm: usuário definido no oracle como identified externally

• <sid>adm: usuário NT pertencente ao grupo ora_SID_dba• sapservice<sid>: usuário NT pertencente ao grupo ora_SID_oper• OPS$<sid>adm: usuário definido no oracle como identified externally

Quando o parâmetro OS_AUTHENT_PREFIX=OPS$ é codificado no init<SID>.ora, isto indicaráque o usuário <sid>adm (OPS$<sid>adm) poderá se conectar ao oracle sem autenticação. Isto será necessário para determinadas tarefas restritas de administração. Neste caso a autenticação do

fica a cargo do sistema operacional.

O mecanismo de conexão dos work processes com o shadow process no Oracle funciona daseguinte forma: o work processes tenta a conexão através do usuário SAPR3/SAP. Caso a senhatenha sido alterada, o que é aconselhável, a conexão é recusada e o work process tentará umaconexão através do usuário OPS$<sid>adm (que não exige autenticação) e acessa a tabelaSAPUSER (cujo owner é o próprio user OPS$<sid>adm) e através dela possui a senha para o

O programa chdbpass (no unix) quando utilizado para alterar a senha do usuário SAPR3 já grava nesta tabela OPS$<sid>adm.SAPUSER a nova senha. O NT que não possui este programadisponível o que torna necessário a inclusão manual da senha na tabela quando se altera o usuáriovia alter user. A conexão remota dos work processes entretanto com o banco R/3 através do userOPS$ somente se dará se o parâmetro REMOTE_OS_AUTHEN estiver setado para TRUE.

NET8 Basis

A comunicação dos work processes com o Oracle se dá através de comunicação TCP/IP atravésda rede. A camada Oracle que interpreta e aceita estas conexões é o NET8. Para que o NET8 aceite

62

conexões através da rede, o listener do Oracle precisa estar ativo. O utilitário lsnrctl80 é utilizado nodatabase server para dar start e stop no processo tnslsnr que executará o serviço.

.../net80/admin do oracle configurarão o serviço NET8:• tnsnames.ora: contém a lista dos serviços para todos os bancos de dados acessados na rede• sqlnet.ora: contém, no lado client, informações do default domain além de parâmetros

opcionais de diagnósticos usados para trace e logs do client• listener.ora: usado no database server e contém Oracle system Ids com o quais o Oracle

poderá receber conexões e parametrizações do listener

Database Monitoring

Várias transações são utilizadas no R/3 para monitorar a base de dados: A DB16 é um systemcheck monitor, a DB12 é o monitor de backup, a DB02 a transação utilizada para monitorar os objetos(tableas, índices, tablespaces) do banco. Além destas, a ST04 é o monitor de performance e a DB14é o monitor das logs das atividades administrativas do banco.

63

Backup Estrategy

Database Backup

A estratégia de backup da base de dados é necessária para garantir a recuperação de uma basede dados que pode falhar por diversos fatores, sejam físicos (crash de disco), lógicos (operaçãoindevida nos aplicativos) ou fatores externos (fogo, agua, greve, etc). Através de cenários que iremosestudar, é possível fazer full recoveries (recuperação total) dos data bases ou ainda recuperaçõespoint in time (recuperação total em um ponto do tempo passado) a partir de uma boa estratégia debackup.

Operações de recovery, por serem críticas, exigem documentação detalhada, estratégia estudadaalém de skill específico dos administradores de banco de dados. Ou seja, antes de tomar qualqueração após um problema, tenha certeza do que está sendo feito e de que a ação é a melhor opçãoentre outras analisadas.

Os files que compõem uma base de dados Oracle podem ser divididos em cinco grupos:• Os data files são os arquivos que contém os dados da aplicação propriamente ditos. É

aconselhável que sejam protegidos por espelhamento (RAID V ou superior)• Os online redo log files são os arquivos onde são gravadas as logs de transações no banco

de dados e são espelhadas por definição através das mirrlogs • Os control files são os arquivos que possuem as informações de controles referentes aos

datafiles e a base de dados. O Oracle mantém cópias deste file em mais de um filesystem doambiente, definido por parâmetro na initSID.ora

• Profiles são os arquivos de configuração da instância oracle• Offline redo log files são as cópias das online redo efetuadas pelo ARCH no momento dos

switch. É recomendado que estes files sejam espelhados e, quando transferidos para fita,sejam replicados em fitas distintas

Um processo de backup de banco de dados copia para outro dispositivo os data files, os onlineredo log files, os control files e as profiles. Um processo de backup do offline redo log file copia osoffline redo log files e as profiles para outro dispositivos. Para garantir a integridade física da base de dados ou seja, garantir que as tabelas e blocos estejam fisicamente íntegros é necessário efetuarlogical data checks através de ferramentas oracle como o utilitário dbv (database verify). Temos

integridade das fitas backupeadas é necessário efetuar um physical datacheck, que verifica a integridade física das fitas gravadas através da leitura dos dados backupeadosna fita.

Backup Types

Um processo de backup offline é executado com a instância em shutdown e os seguintesarquivos são copiados: data files, online redo log files, control file e profiles (init<SID>.ora, .sap e.dba). Um processo de backup online é executado com a instância ativa e os seguintes arquivos sãocopiados: data files, control file e profiles. Estas cópias online não são consistentes, já que o processode update no banco continua sendo efetuado pelos usuários. Um recovery a partir de um onlinebackup somente tem sentido com o cruzamento das logs (redo logs) geradas no decorrer doprocesso. Um processo de partial backup pode ser utilizado para diminuir o tempo gasto noprocesso. Neste caso apenas alguns tablespaces serão copiados em cada dia até fechar um ciclo. Independente do processo utilizado (offline ou online) este backup é inconsistente e precisa dasoffline redo log de todo o ciclo para permitir um recovery do database.

Outro processo para diminuir a janela de backup é através do paralelismo do backup com autilização de vários drives de fita. Este processo reduz significantemente o tempo de backup erestore, sendo porém caro pelo hardware envolvido.

64

Backup and Recover Diagram

Data Loss

Várias são as causas que podem causar a perda de dados em uma base de dados.podem ocorrer pela deleção indevida de objetos do banco de dados (um data file), um drop em umatabela ou ainda por erro de aplicativo que provoca a perda de dados. Erros lógicos são recuperados

um full database restore seguido de um point in time recovery até o momentoimediatamente anterior a causa da perda da informação.

A ausência de um offline redo log file durante um processo de recovery causará a perda detodas as informações subsequentes, já que o processo não permite a aplicação dos offline seguintesao que foi perdido. Por este motivo é importante a manutenção de pelo menos redo log files em dispositivos diferentes para garantir uma recuperação com uma salva-guarda decontingencia.

Uma outra causa de necessidade de recuperação é o chamado disaster recovery, efetuado porcausas físicas, como por exemplo um crash de disco. A manutenção de cópias de backup em cofresgarantem inclusive a possibilidade de recuperação de todo o ambiente computacional em caso deperda total das instalações físicas do cpd.

Backup Recommendations

Alterações nas estruturas dos arquivos afetarão os restores subsequentes, como ocorre porexemplo quando um data file é acrescentado a base de dados. Processos como este que causam a

backup adicional imediato do banco de dadospara que o processo de recuperação, se houver, não seja afetado pelo diferente estado do banco dedados. O ponto crítico de uma alteração estrutural do banco de dados é a necessidade de ter ao menos uma cópia do novo datafile e a estrutura gerada no control file. Sem isto é impossívelrecuperar o banco na nova estrutura ou fazer um log-foward após este evento.

Backup Cycle

A SAP recomenda um ciclo de backup de 4 semanas. Isto significa que os offline redo log filesserão backupeados diariamente e mantidos por 28 dias. O backup online deve seguir a mesma regra,

Backup

ArchiveLog NoArchiveLog

On-Line Off-Line

Complete Recover

Incomplete Recover

withreset log

Reset

65

ou seja uma cópia a cada dia útil do ciclo. É importante ainda que tenhamos em cada ciclo pelo menos um backup offline, um check de consistência do backup e check dos datafiles do banco dedados. Esta recomendação é básica, sendo o ideal fazer tudo isso pelo menos uma vez a cadasemana. É recomendável também que os arquivos do backup online fiquem em fitas diferentes dobackup do offline redo log. Isso viabiliza novas alternativas para os planos de contingencias caso as fitas também apresentem problemas.

Final Recommendations

Utilize as ferramentas providas pela SAP para efetuar o backup (BRBACKUP e BRARCHIVE) etenha certeza que elas estão configuradas corretamente. Para um evetunal restore do banco dedados utilize a ferramenta BRRESTORE. Estas ferramentas que efetuam o backup e o restoretrabalham integradas ao sapdba e se baseiam em logs próprias gravadas no sistema operacionalpara direcionar o seu funcionamento.

É bom lembrar que além do banco de dados, é necessário manter backup consistente de outrosobjetos R/3, tais como archiving, interfaces, executáveis e do sistema operacional. Não adianta muitoter o backup da base de dados se não tivermos o R/3 e o Oracle instalados e com os arquivos de

Só a correta implementação de uma boa estratégia de backup é a garantia para a recuperação dosistema sem perda de informações em caso de falhas.

66

Scheduling, Performing and Monitoring Bac kups

Backup Tools Features

Para fazer um backup podemos utilizar uma das ferramentas :• Transação DB13 - DBA Planning Calendar - onde é possível schedular backups periódicos em

• Utilitário SAPDBA onde é possível ativar backups esporádicos de forma interativa por menus evárias outras operações de administração e operação do oracle

• BRBACKUP e BRARCHIVE onde –e possível realizar backups a partir de linha de comando

Backup profile parameters

Alguns dos parâmetros podem possuir valores default definidos na profile init<SID>.sap, como porexemplo o tipo de compressão, comando para compressão, utilitário para cópia, dispositivo a serutilizado, etc. Os utilitários brbackup e brarchive atualizam as tabelas SDBAD e SDBAH, checa o lockde fitas e gera logs específicas das atividades efetuadas sempre levando em conta a parametrizaçãofeita neste arquivo.

tape_size Parameter

O parâmetro tape_size da init<SID>.sap define o volume de dados que cabe no modelo de fitautilizado tanto para o BRBACKUP quanto o BRARCHIVE. Este parâmetro é importantíssimo já que asua má especificação pode causar mal funcionamento do processo de backup. Através daespecificação do parâmetro tape_size os utilitários de backup (BRBACKUP e BRARCHIVE) calculamo volume de dados que pode ser enviado para cada fita, dimensionando desta forma o número defitas que serão necessárias durante o processo. Quando mal dimensionado pode causar o desperdício de mídia ou, pior ainda, erro no processo de gravação. O utilitário dd utilizado noprocesso de cópia acusa erro quando atinge o end-of-tape. Já o utilitário cpio, desde que não estejatrabalhando em modo parallel, consegue passar os dados para um volume subsequente, porém estevolume não será reconhecido pelas ferramentas de gerencia de fitas por ter sido requisitado ao longodo processo e não possuir o arquivo de identificação da fita (.tape.hdr0). O ideal portanto é que este

10% menor que a capacidade real da fita, como margem desegurança.

Quando utilizamos compressão por hardware, o valor do tape_size deverá ser ainda um poucomais folgado, uma vez que a taxa de compressão varia dependendo do tipo de dado armazenado. A nota 8707 dá todos os detalhes sobre esta especificação de tape_size.

Para distribuir os files pelas fitas, o brbackup utiliza informação da dos files.Este cálculo da taxa de compressão deverá ser efetuado uma vez a cada ciclo através do comando

. Quando utilizado tape stations com hardware compression, o parâmetro compress_cmd da init<SID>.sap deverá ser setado para “compress –b 12 –c $ > $” (em unix). Acompressão por software é efetuada no diretório especificado (compress_dir) e consumirá ciclos de

Phases of Database Backup

Um backup online é executado com o banco de dados ativo causando durante o processo umacerta concorrência nos datafiles. Os seguintes processos são efetuados durante o processo.

• Salva a saída de um backup control file em disco• Obtém os files names que serão backupeados • Backup do tape header, e das profiles (inits ora, sap e dba) • Coloca os tablespaces em backup mode, efetua backup dos datafiles e retira o backup mode • Backup do control file

67

• Faz um log file switch• Backup de logs (reorg.log, struct.log, detail.log, summary log)

O backup offline é efetuado com o database em shutdown, porém o brbackup deixa a instância noestado exato em que se encontrava no início do processo (up ou down):

• Start no database, se o mesmo se encontra em shutdown• Obtém os files names que serão backupeados • Shutdown no database• Backup do tape header, e profiles • Backup dos datafiles• Backup dos online redo log files• Backup do control file• Start no database• Backup de logs (reorg.log, struct.log, detail.log, summary log)• Deixa o banco no estado inicial, (up ou down)* Eventualmente, se o backup offline não for completo os online redo log não serão backupeados

Database Backup Check and Monitoring

Blocos de dados danificados no banco de dados somente são identificados quando o Oracle tentarmanipular este bloco. O utilitário dbv da Oracle efetua o check de um datafile quanto a estasintegridades.

Esta verificação lógica da integridade dos dados pode ser realizada em tempo de backup através. Este processo faz com que os files

sejam lidos da fita após gravados e transferidos para o diretório de compress (compress_dir) ondesão processados pelo utilitário dbv da Oracle. O processo além de detectar blocos corrompidosgarante a disponibilidade da fita. È aconselhado que seja efetuado uma vez por semana ou nomínimo uma vez no ciclo. Como este processo pelo menos duplica o tempo gasto no backup, épossível adiar a execução do verify através de uma execução posterior de uma simulação deBRRESTORE, que pode inclusive ser executado em outra máquina. (Para maiores informações dedatafiles corrompidos veja a nota 99962).

A opção de verificação da integridade lógica (-verify use_dbv) verifica a integridade dos blocosOracle porém não garante que o file gravado na fita seja idêntico ao file existente no disco. Estaverificação da integridade física deverá ser efetuada uma vez no ciclo, que ocorrerá a nível bináriocom a especificação do parâmetro (-verify ou –w). Este processo de verificação física somente podeser executado no processo de backup offline e também irá provocar a leitura da fita para que o fileseja transferido para a área de compress. Este processo duplica o tempo de backup e,diferentemente do anterior, não pode ser postergado para um posterior BRRESTORE.

O BRBACKUP grava logs em files no diretório sapbackup e nas tabelas SDBAH e SDBAD quedevem ser checados constantemente. Os logs gravados obedecem a um padrão próprio denomenclatura (b<timestamp>.<ext>) cuja extensão depende do tipo de backup selecionado. Astransações DB12 e DB13 também permitem acompanhar a execução dos backups

Offline Redo Log Files Backup

O processo Oracle ARCH é responsável pela movimentação as Online redo log files durante oswitch de log. Estas logs são transferidas para a área saparch e devem ser transferidas para fitas detempos em tempos. Este processo é denominado Offline redo log backup e é efetuado pelo programaBRARCHIVE. O BRARCHIVE loga o status dos offline redo log files em um arquivo denominado arch<SID>.log, que se localiza na saparch e grava linhas referente às atividades executadas com osredo log files :

• ARCHIVED: estado indicando que o file foi arquivado • SAVED: indicando que uma gravação para fita foi efetuada• COPIED: indicando que uma segunda cópia foi efetuada• DELETED: indicando que o file foi deletado do diretório

68

O BRACHIVE possui uma serie de opções para o backup dos archive logs. A SAP aconcelha a no BRARCHIVE que faz com que esta gerencia de backup duplo

de offline redo log files com posterior deleção seja efetuado automaticamente. Outra boa opção e a opção –f (fillup) onde o brarchive grava os files e continua verificando a saparch de tempos emtempos. Qualquer offline que apareça é então gravado até que a fita esteja cheia.

Como no BRBACKUP, devemos utilizar a opção –verify ou –w para efetuar um check físico dosarquivos gravados e é recomendado que seja efetuado uma vez no ciclo.

A monitoração do processo de offline backup deverá ser efetuado através da transação DB12 eatravés da monitoração do arch<SID>.log no diretório saparch. Através da forçar a gravação de mais informações na log.

Log File Cleanup

Os logs gerados tanto pelo BRBACKUP quanto pelo BRARCHIVE são utilizados posteriormentepelo SAPDBA para tomar as ações corretivas e parametrizar o BRRESTORE. Estes files porém vãose acumulando nos diretórios e precisam ser eliminados de tempos em tempos. O SAPDBA possui

clenup não só destes logs como também dos traces e logs geradas peloOracle e pelo próprio sapdba. A limpeza dos logs de backup e archive se baseia nos parâmetrosexpir_period_* da init<SID>.dba. Estes parâmetros deverão ser adaptados de acordo com o ciclo de backup adotado na empresa. A chamada a estas funções poderá ser executado interativamente via

em linha de comando ou via algum utilitário deagendamento do sistema operacional.

Freespace Administration

Os offline redo log files são transferidos para a área de archive saparch através do serviço OracleARCH. Se estes arquivos não forem backupeados para fita e deletados, a área poderá estourar, oque causa a parada do Oracle conhecida como archiver stuck. Neste caso a instância para por nãopoder sobrescrever um online redo log file ainda não transferido para a área de offline. Este problemasomente ocorre se o ARCHIVELOG mode estiver ativado, o que é padrão em ambientes produtivos.Através da DB12 deve-se monitorar a área livre no diretório (ou através de df –k) e tomar medidaspreventivas (archive) antes que o problema ocorra.

Outra solução que pode ser adotada é a definição de um arquivo dummy grande o suficiente paraque, em caso de archiver stuck, ele possa ser removido dando ao sistemas mais alguns minutosenquanto se processa o archive. Caso o sapdba não mais responda a comandos, ative o brarchivevia linha de comando

One-Run Strategy

A estratégia One-Run backup consiste em efetuar o backup e o archive em uma única chamadaao br backup através da especificação de parâmetros próprios ( ).Neste caso apenas uma fita do pool backup (volume_backup) é utilizada para armazenar os doisbackups. Esta estratégia porém só pode ser utilizada se o backup dos datafiles e todos os offlineredo log files couberem em uma única fita. A solução neste caso é o uso de paralelismo no backup(mais de um drive) ou então adotar outra estratégia para o backup.

Esta solução possui o incoveniente dos datafiles e ds offline redo log files estarem na mesam fita.Além disso, em caso de um archiver stuck ocorrer, esta opção não poderá ser usada, já que obrbackup tentará se conectar com o banco que se encontra travado.

Further Documentation

Para maiores informações sobre backup e recover, veja as notas 96896, 19909, 99088, 71058,8707, 33630, 99962, 23345, 100400 e 83699.

69