WORKSHOP BASIS

Workshop Basis
Outubro/2011

Vitor Oliveira

Contedo e Acesso ao Documento:

As informaes apresentadas neste documento foram geradas pela Firsteam atravs de anlises efetuadas no ambiente.O contedo deste documento considerado sigiloso, destina-se ao uso exclusivo da Lupo e deve ser utilizado internamente, para avaliao de seus termos, aprovao e acompanhamento do projeto.

SUMRIO
R/3 BASIS TECHNOLOGY..........................................................................................................4 . SYSTEM KERNEL ........................................................................................................................7 INTERFACES................................................................................................................................13 R/3 . GRAPHICAL USER INTERFACE.........................................................................................16 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 BACKUPS66

R/3 Basis Technology

Basis System and the System Environment The Integration Model
Sistema R/3 composto dos seguintes mdulos: Logstica 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 (no vem no standard) A camada Basis integra todos estes mdulos. a parte central do diamante do diagrama do R/3 e as demais so os mdulos funcionais. Estes mdulos se interconectam e interagem para garantir que o sistema todo integrado, tanto na parte de processos quanto em relao a base de dados.

Business Framework Architecture

O Business Framework Architecture (BFA) a arquitetura estratgica do produto R/3. Ela trabalha com business components que so os mdulos funcionais (FI, CO, etc.) configurveis para se adaptar a cada empresa. Esta arquitetura fornece agilidade para se adaptar a um novo negcio, alm da facilidade de se integrar com pacotes externos e fcil integrao com a internet e intranet, permitindo desta forma uma fcil evoluo sem a interrupo da operao do negcio da empresa. O princpio da arquitetura que cada componente possui vida prpria e sua complexidade esta restrita a ele mesmo. Para o mundo externo somente os mtodos de interfaceamento so visveis e acessveis, fato que garante a total conexo deste com os demais sem causar grandes impactos ou interferncias O Business Framework se mostra no R/3 como uma famlia de componentes separados porm Business Components: so os mdulos funcionais (FI, CO, etc.) so formalmente conhecidos como componentes relativos ao negcio; Business Objects: Ordem, Empregado, Material, etc. So o prximo nvel de hierarquia do R/3. Pertencem a um Business component e podem ser considerados como objetos bsicos do sistema; BAPI Interfaces: So os mtodos com que os objetos de negcio so implementados dentro do R/3 (criar uma ordem, alterar o endereo de um empregado, etc.) e eventualmente podem ter mais de uma verso para o mesmo interfaceamento.

A forma bsica de distribuir as informaes o ALE e este ser detalhado mais a frente.

R/3 as an Open System

O R/3 utiliza protocolos standard da industria para garantir a integrao com outras aplicaes: TCP/IP: o protocolo de comunicao difundido mundialmente; EDI: Electronic Data Interchange, o mecanismo utilizado para trocar informaes de negcio com diferentes sistemas; muito utilizado pelos bancos; OLE: Object Linking and Embendding, integra aplicaes PC com o R/3 (padro microsoft); Open Interfaces, tais como arquivamento tico, dispositivos de cdigos de barras, etc. Alm de standard da indstria, o R/3 tambm utiliza RFC: Remote Function Call, que utiliza o protocolo copiado do CPI-C da IBM para comunicao e processamento das aplicaes e tasks dentro do sistema R/3 ou com o sistema R/2 ou outros sistemas; ALE: Application Link Enabling permite o processamento distribudo dentro do R/3. Na prtica est associado a distribuio de informaes a partir de um modelo de divulgao preestabelecido;

Scalability and the Client/Server Concept

O R/3 possui uma arquitetura modular de software seguindo o princpio da arquitetura cliente/servidor com enfoque na distribuio da fora de processamento entre as vrias plataformas envolvidas. Esta arquitetura permite que se separe a lgica da aplicao da base de dados e da camada de apresentao. Esta configurao permite ainda otimizar os custos e distribuir a carga atravs de configuraes variadas de hardware. Com isto possvel dimensionar os servidores de acordo com a carga, permitindo a fcil escalabilidade do ambiente. Os ganhos nesta arquitetura na implementao R/3 so muitos: Simples instalao de novos servidores para eliminar eventuais gargalos de processamento; Servidores trabalham em paralelo, com carga homognea e execuo local dos programas; Baixo trfego de rede com a localizao dos buffers de dados e programas prximo de onde Balanceamento de carga, seja para o processamento online (logon) seja para o processamento batch.

Ou seja, o ponto alto da arquitetura a facilidade para escalar e aumentar o poder de processamento

Client/Serve Principles
Na implementao R/3, a arquitetura client/server orientada para o software, e no para o hardware como estamos acostumados a ver. Desta forma, Client quem requisita e utiliza o servio e

Um servidor de aplicao por exemplo server de alguns servios das estaes clients, porm client dos servios 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 no importando quem tem mais hardware ou quem normalmente executa a atividade.

R/3 System Client/Server Configurations

Os servios (ou camadas) fundamentais de uma aplicao so trs: Presentation, Application e Database services e existem vrias formas de se implementar um sistema R/3, a saber :

Central, onde todos os componentes esto implementados em um mesmo host. Esta implementao corresponde a clssica implementao mainframe e no comum de ser implementada; Two-tier, onde uma camada normalmente executa as funes de presentation (usualmente um PC) e a outra camada executa os servios de application e database. Uma outra implementao two-tier poderia ser uma camada executando os servios de database e a outra composta por PCs mais potentes que executariam as funes de presentation e application. A primeira implementao comum em ambientes pequenos e com pouca disponibilidade de hardware para os servidores. A ltima implementao normalmente utilizada em simulaes ou desenvolvimento de software. Three-tier, onde cada servio tem o seu prprio host. Nesta configurao possvel ainda assegurar uma diviso de carga na camada de aplicao, garantindo que determinados hosts fiquem dedicados para aplicaes especficas. Por exemplo dedicar um host para servidor de aplicao dos usurios de MM, ganhando com isto performance na distribuio dos servios.

A configurao three-tier a mais recomendada em R/3 por garantir a melhor distribuio de carga e escalabilidade nos grandes sistemas. Todos os servidores em uma configurao R/3 devem

Um sistema R/3 agrupa todos os componentes que esto associados com um banco de dados. Se utilizamos uma implementao em 3 camadas, os componentes do R/3 estaro presentes em todas as camadas da hierarquia: Database Server, instalado em um host central, onde todos os servios de bancos de dados Um ou mais Application Servers conectados ao servidos de banco de dados. Nestes servidores estaro sendo processados a lgica da aplicao, ou seja, os programas. Vrios Presentation Servers conectados aos servidores de aplicao. Estas mquinas so tambm chamadas de frontends ou workstations. Nestas mquinas os usurios iro interagir com o sistema R/3 utilizando uma interface que prover os servios de presentation.

The Middleware Basis

O software Basis do R/3 (tambm chamado de middleware) roda em diferentes plataformas e tambm pode ser adaptado para atender as necessidades individuais das empresas. So vrios os Prov o ambiente de runtime para as aplicaes R/3 Cuida da perfeita interao das aplicaes com o sistema Define uma arquitetura estvel para as melhorias do sistema Contm todas as ferramentas necessrias para a administrao do ambiente Permite a distribuio eqitativa dos recursos e componentes do sistema Prov as interfaces necessrias para os sistemas descentralizados e os produtos externos ao R/3

As principais caractersticas da tecnologia Basis so: uma arquitetura voltada para a configurao client/server Trabalha com bancos de dados relacionais Possui interface grfica com o usurio (GUI) Basis o responsvel ainda pela integrao 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 bsico so divididas em suas prprias camadas que variam de sistema para sistema (NT ou UNIX, Oracle ou Informix, etc.). Acima destas camadas as funcionalidades dos componentes R/3 so basicamente as mesmas, independentemente do hardware, software ou sistema operacional.

System Kernel
R/3 Presentation Interface
A interface de apresentao do R/3 o SAPGUI que apresenta uma funcionalidade muito parecida entre as diversas plataformas do R/3. Um usurio treinado em uma determinada plataforma, salvo pequenas excees est apto a operar o sistema nas suas mais diversas implementaes. O fluxo de informao entre o SAPGUI e o servidor de aplicao no consiste de telas preformatadas, mas sim de strings lgicos contendo dados e caracteres de controle, o que faz com que o trfego de dados se mantenha na casa de 1 a 2K por tela (cada enter). Estes strings so na verdade um protocolo de comunicao 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 o application e o sapgui, e a ordem de processamento est na dispatche queue ou request queue. A regra sempre obedecer a FIFO (first in, first out).

R/3 Database Interface

O R/3 trabalha com bases de dados relacionais, que so compostas de tabelas bidimensionais e interagem com os sistemas atravs da linguagem padronizada SQL (Structured Query Language) que comum a todas as implementaes de bases relacionais, embora cada fabricante implemente algumas extenses no seu produto. O DB Interface um mdulo dentro do R/3 que converte os comandos SQL codificados nos programas ABAP para o SQL nativo do banco implementado em cada ambiente R/3. Ou seja, cada implementao (Oracle, Informix, SQL Server) possui um mdulo de DB Interface particular para aquela implementao, o que torna os programas ABAP independentes da implementao do banco. Estes comandos SQL escritos no ABAP so denominados OPEN SQL e o DB Interface responsvel pela sua correta transcrio para o SQL nativo do banco. Alm disso, um programa ABAP pode codificar o comando diretamente em Native SQL. Neste caso o comando no passar pelo DB Interface, indo diretamente para a DB machine. Estes comandos podero no ser independentes do banco utilizado, se utilizarem extenses particulares de um determinado RDBMS. Os comandos SQL escritos em OPEN SQL tem sua sintaxe verificada pelo DB Interface que inicialmente faz um acesso no buffer interno do application server para evitar acessos desnecessrios ao DB server. Comandos escritos em native SQL no fazem uso deste buffer interno, uma vez que o

Normalmente as tabelas que vemos no R/3 so armazenadas no DB. Estas tabelas so conhecidas com tabelas transparentes. Elas so implementadas no DB exatamente como vemos no dicionrio do R/3. Existem outros tipos de tabelas que so declaradas no dicionrios mas no so implementadas exatamente como aparecem. As tabelas do tipo Pool so declaradas no banco como uma s mas para o R/3, aparentemente, so tabelas como outras quaisquer. Este recurso utilizado para tabelas de poucas ocorrncias e para evitar um grande nmero de tabelas. Existem tambm as tabelas tipo Cluster. Essas so uma desnormalizao do dado dentro do modelo relacional. Mais precisamente como se tivssemos o conceito de campos mltiplos dentro de um registro (que infringe a primeira regra normal). O DB Interface no o processo que acessa e mantm a conexo com o banco. Este processo conhecido como shadow process e roda na mquina onde est o banco de dados fazendo a ligao do db interface, que est na maquina onde est a instance, e o banco de dados.

Work Processes and Dispatcher

Os principais componentes de um application server so: Um dispatcher como o controle central da instance Dispatcher queues para enfileirar as requisies (FIFO) Um nmero configurvel de work processes para processar os programas ABAP Buffers e shared memory. Os work processes so servios dentro de um sistema R/3 especializados em determinadas tarefas. O centro de um sistema R/3, a nvel de controle de aplicao, o Dispatcher. Ele, juntamente com o sistema operacional, o responsvel pelo controle e disponibilizao dos recursos do sistema. Suas principais tarefas so o controle da comunicao, a conexo com o presentation e a distribuio de carga entre os work processes. O dispatcher distribui os servios requisitados entre os WP disponveis e se encarrega de enviar o dado processado para o SAPGUI, que dever interpret-lo e exibir para o usurio. No existe um WP fixo para um determinado usurio, cuidando o dispatcher de ir utilizando-os conforme as requisies vo chegando, em um processo de fila FIFO. Quando um sistema R/3 inicializado, o dispatcher o responsvel por lr os parmetros de configurao (profiles), gerar as rol areas, inicializar os work processes e se conectar com o message server da central instance. Cada dialog work process coordenado por um componente interno denominado Task Handler. Ele ativa o screen processor ou o ABAP processor e ainda o responsvel pelo roll in e roll out das reas de usurio. Existem memrias de uso exclusivo de um determinado work process e memrias que podem ser compartilhadas por todos eles. Esta diferenciao gerenciada pelo memory management. A memria utilizada exclusivamente por um work process possui duas reas reservadas para dados especficos de uma determinada sesso de usurio (user context area) e devem ser mantidas entre as pseudo conversas do dialog. Estas reas so denominadas roll e paging areas. A roll area contm dados que ficam imediatamente disponvel para o processamento no incio 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 usurios. Nesta rea so salvos os dados referentes ao usurio (user context) tais como suas autorizaes, informaes administrativas alm de dados adicionais para o ABAP e dialog processors, que so dados que j foram coletados por dialog steps anteriores.Na shared memory existem dados disponveis para todos os work processes, tais como o calendar, screen, table e program buffers.

R/3 Application Services

Um sistema R/3 composto de uma srie de work processes que funcionam em paralelo cooperativamente. Cada application server possui um dispatcher e um nmero configurvel destes processos, que depende dos recursos disponveis no host (basicamente memria e processamento). Work processes podem ser instalados para efetuar servios de dialog, update, background e spool. Uma central instance possui ainda servios de enqueue (que tambm um work process) para gerenciamento de lock e dois outros servios prprios: Message Server responsvel pelo servio de comunicao entre os vrios dispatchers que compem um sistema R/3, que portanto um pr requisito para a escalabilidade de vrios servidores de aplicao trabalhando em paralelo. Ele muito usado para a troca de dados de controle. Gateway Server, tambm chamado de CPI-C handler, que permite a comunicao entre R/3, R/2 e aplicativos externos. muito utilizado para trocar dados da camada da aplicao, incluindo ai dados da mesma instncia. Resumindo, uma instncia nomeada pelos servios que ela presta. Um bom exemplo disto a instncia DVEBMGS00 que possui dialog, update, enqueue, batch, message, gateway e spool e todos respondendo pelo system number 00 que significa que a porta 3200 ser utilizada pelo sapdp00

(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 Dialog Update Enqueue Background Message Gateway Spool R/3, System-wide >= 2 >= 1 1 >= 2 1 >= 1 >= 1 For each R/3 Instance >= 2 >= 0 0 ou 1 >= 0 0 ou 1 1 >= 0

R/3 Transaction and LUW

Transaes so unidades de processamento agrupadas em funes que executam alteraes consistentes na base de dados, de acordo com a funcionalidade a que se propem. Um exemplo tpico seria o dbito em uma conta para crdito em outra, que somente fazem sentido consistente quando executadas como um todo. Uma transao SAP implementada atravs de uma srie de dialog steps consistentes e conectados de forma coerente. Uma transao SAP no executa necessariamente em um nico work process, uma vez que cada um dos seus dialog steps podero estar sendo atendidos por WP diferentes que o dispatcher encontrou disponvel em cada momento. Alm disso, quando se utiliza o asynchronous update para processar as atualizaes da base de dados, estes processos estaro sendo atendidos por outros work process que podero inclusive se encontrar em outros hosts. No R/3 cada dialog step composto de um processamento que inicia aps o usurio entrar o dado (PAI Process After Input) e pelo processamento e envio da prxima tela (PBO Process Before Output). Do ponto de vista do usurio, cada dialog step comea com o preenchimento de uma tela e o posterior processamento at o envio da prxima tela. Para o sistema apenas as partes referentes ao processamento (PAI e PBO) compem o dialog step j que durante o preenchimento da tela nenhum

Este conceito de transao, que pode compor de um ou vrios dialog steps, chamado de LUW, ou Logical Unit od Work. Como os bancos de dados no suportam o conceito de transao para todos os processos conversacionais (begin/end transaction commands), necessrio saber diferenciar uma transao do ponto de vista SAP (SAP-LUW) de uma transao de banco de dados (DB-LUW) que totalmente executada ou totalmente desfeita. No existe meio termo numa DB-LUW. Enquanto uma SAP-LUW garante a integridade lgica do banco de dados (um determinado lanamento dever existir nas tabelas x, y e z), uma DB-LUW garante a integridade fsica do DB e executado necessariamente pelo gerenciador do banco. Uma transao SAP inicia uma SAP-LUW que somente termina ao encontrar um comando COMMIT WORK no programa ABAP ou ento no final do asynchronous update.

Lock Concept and Asynchronous Update

A tcnica principal utilizada numa SAP-LUW a atualizao assncrona, onde as requisies de update na base de dados so coletadas separadamente e iniciam aps o COMMIT WORK, onde so executadas em uma nica DB-LUW para garantir a integridade do banco. Os mecanismos de lock existentes nos gerenciadores de bancos de dados no so suficientes para garantir a correta manipulao dos objetos de negcio, que muitas vezes envolvem uma srie de tabelas em um nico lanamento. Com o seu prprio mecanismo, O R/3 assegura que determinados

dados permaneam protegidos durante todo o processo de atualizao do objeto. Esta tarefa executada pelo Enqueue Work Process que utiliza uma tabela armazenada na memria principal (de onde o enqueue work process est rodando, tambm conhecido como enqueue server e normalmente a central instance) para este gerenciamento. Sempre que um lock requisitado o sistema verifica (atravs do enqueue wp) se a requisio no fere outro lock j postado na tabela. Havendo coliso de interesses, o processo informado atravs de uma mensagem de erro, o que permite ao programa ABAP informar ao usurio que a sua operao no poder ser executada no momento. Caso o enqueue work process no se encontre na mesma instance em que o processo est correndo, o que normal em uma sistema R/3 de tres camadas, esta comunicao efetuada pelo message server. Para que este mecanismo de requisio de lock funcione no sistema R/3, necessrio que um objeto de lock seja definido no dicionrio ABAP especificamente para aquele objeto que se deseja travar. J existem objetos definidos em uma tabela primria no dicionrio do R/3, porm o usurio pode definir seus prprios objetos em tabelas secundrias (estes objetos do usurio precisam ter

Os locks podem ser do tipo S (read) ou E (write). Um lock do tipo E somente poder ser postado se no existe nenhum outro lock j definido sobre o registro. Quando um objeto de lock ativado, o sistema gera duas funcion modules, uma para ENQUEUE_<object> e outra para DEQUEUE_<object>. Os lock postados por um programa permanecem at que sejam retirados pelo prprio programa ou ainda pelo procedimento de update (segunda parte da SAP-LUW). Work processes podem gerar atualizaes diretamente na base de dados mesmo que o banco no se encontre no mesmo host. Quando o programa ABAP utiliza os comandos CALL FUNCTION ... IN UPDATE TASK, criado no R/3 o mecanismo de asynchronous update. Neste caso a requisio direcionada para uma tabela (a VBLOG) existente fisicamente no banco de dados que age como um buffer intermedirio onde as requisies de atualizao so enfileiradas. Esta tabela contm basicamente o nome da rotina que ser disparada para efetuar a atualizao e os dados (parmetros) para a rotina efetuar as atualizaes necessrias. Transaes que so canceladas pelo usurio no tem o seu registro de header completado na VBLOG e portanto suas atualizaes no so efetuadas. Os registros de atualizao podem ser divididos em componentes V1 e V2. Basicamente processos que so crticos so armazenados em componentes V1 e processos secundrios que so menos time-criticals so armazenados nos componentes V2. Informaes de

O processo assncrono de update disparado pelo comando COMMIT WORK especificado no ltimo dialog step de uma SAP transaction. Nesta fase que ocorre na segunda parte da SAP-LUW, os registros escritos na VBLOG so recuperados e atualizados fisicamente na base de dados. Caso ocorram erros nesta fase em processos V1, as alteraes no DB daquela DB-LUW so desfeitas por rollback e os registros permanecem na VBLOG assinalados com um flag de erro. Caso ocorram erros em processos V2, apenas aquele registro ser setado com erro e as demais atualizaes V2 continuam sendo executadas. Quando ocorrem os erros descritos acima, o usurio notificado atravs de mail e medidas corretivas precisam ser avaliadas. Ao trmino da SAP-LUW, a task de update remove os locks postados pelos dialog steps anteriores. Caso ocorram erros durante o update os locks tambm sero removidos. Updates pendentes com erro podem ser restartados pelo administrador do sistema. A SAP no recomenda que updates V1 sejam restartados, devendo este procedimento somente ser efetuado para updates dos tipo V2. Processos V1 devero ser regerados processando novamente a transao (veja a nota 16083) Quando um sistema R/3 sai, as entradas que esto com status INIT na VBLOG so processadas to logo o sistema retorne ao ar. Esta funcionalidade pode ser parametrizada pela profile do sistema. Resumindo uma SAP-LUW, onde cada tpico um dialog step : usurio abre uma transao para atualizar uma determinada informao; Na prtica o SAPGUI do usurio entra em contato com o dispatcher da instncia em questo e aciona o PAI da janela corrente e providencia a exibio da janela desejada;

10

usurio preenche os dados chave para a identificao da informao e o PAI novamente acionado. Neste momento o work process selecionado pelo dispatcher para tratar deste dialog step localiza a informao desejada atravs do DB Interface e solicita ao Enqueue que a respectiva informao seja locada. Isto feito pela funo call function enqueue e pela incluso da lock table que fica na memria da onde esta sendo executado o enqueue. usurio, de posse da janela com os dados a serem atualizados, atualiza a informao e inicia um novo dialog step. Este o dialog step da nossa transao. Ele vai chamar a funo call function in update task que incluir as informaes a serem atualizadas na tabela vblog. Para o dialog work process a atividade encerra quando o commit work realizado. Mas na verdade para o R/3 o assunto ainda no est terminado pois o work process de update, a partir da tabela vblog, vai providenciar que a atualizao seja feita nas tabelas que possuem as informaes reais e call function dequeue. Esta parte da transao, que feita pelo update work process conhecida como a segunda parte da SAP-LUW.

Background Processing
Processos que so schedulados para processamento pelos background work processes so tratados no sistema da mesma forma que os processos online. Processos background so schedulados na forma de jobs. Cada job possui um ou mais steps (que podem ser external ou ABAP programs) que so processados seqncialmente. Atravs das classes de processamento (A, B ou C) possvel setar prioridades entre os jobs. Os jobs batch normalmente no so schedulados para processamento imediato, mas so especificados para uma data/hora futura podendo ainda, quando necessrio, serem definidos como peridicos. O batch scheduler o responsvel pelo disparo automtico dos jobs configurados no sistema. Este mdulo um programa ABAP que roda em um dialog work process por instncia do sistema R/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 jobs batch entre os diversos servers que possuem work processes disponveis (do tipo B). Jobs batch podem ainda ser schedulados para processamento em servers especficos. Na escala de prioridade, para os jobs com mesmo horrio de inicio, os Jobs classe A tem maior prioridade que os classe B e por ltimo os jobs classe C. Dentro de um mesmo servidor e jobs schedulados com a mesma classe, tem prioridade aquele schedulado com especificao explcita de server (sem balanceamento). A partir da a ordem de inicializao definida pela ordem de criao do job. Se for necessrio saber a ordem em que os jobs sero executados basta abrir a SM37, listar os jobs e classifica-los pela ordem cronologica. Se houver alguns jobs no mesmo horrio devemos entrar em um a um para ver a data de criao e descobrir qual a ordem exata de execuo. Se for necessrio bloquear a execuo de jobs, basta setar o parmetro rdisp/btctime = 0

R/3 Printer Services

Spooling a transferncia bufferizada de dados para dispositivos de sada do tipo printers, fax, etc. O R/3 suporta spooling para dispositivos locais ou em rede. As requisies de spool so geradas tanto pelo processamento online (dialog) quanto pelo processamento batch (background). Os dados a serem impressos ficam armazenados nos TemSe (Temporary Sequential Objects). Quando o sistema necessita de impresso, gerado um output request que encaminhado para um spool work process. Uma vez formatado o dado para impresso, a requisio de impresso encaminhada para o spool do sistema operacional, que fica responsvel pelo encaminhamento do output request para o

R/3 Instance
Uma instncia R/3 uma unidade administrativa que combina componentes de um sistema R/3 para prover um ou mais servios. Todos os servios providos por uma instncia so iniciados (start da instncia) e parados (stop da instncia) ao mesmo tempo. Uma instncia parametrizada atravs de parmetros que descrevem todas as suas caractersticas.

11

Cada instncia possui seus prprios buffers e um sistema R/3 central composto de uma nica instncia que possui todos os servios (DVEBMSGnn). O message server o responsvel pela comunicao entre os application servers e um central message service para prover servios de update trigger, enqueue e dequeue, background requests, e outras pequenas trocas de informaes (normalmente dados de controle e pequenas quantidades de dados da camada de aplicao) Cada dispatcher de um application server se comunica com um nico message server em cada ambiente R/3, que portanto s instalado uma nica vez na central instance. ele quem atribui qual work process vai processar o dialog step que est iniciando. O controle desta fila armazenada na dispatcher queue, tambm conhecida como request queue. Alm dos dispatcher, os presentation (SAPGUI) podero se logar nos application server atravs do message server para desta forma efetuar balancemento automtico de carga (load balancing). O gateway o responsvel pela troca de dados (normalmente com bom volume de dados) entre as instncias de um sistema R/3, entre sistemas R/3 e entre um sistema R/3 e outros sistemas So as profiles que configuram as diversas instncias e desta forma definem quem executa quais servios que estaro disponveis. Por nomeclatura costumamos chamar os dialogs, background, enqueue, update e spool de work process e o gateway e message de servios.

12

Interfaces
R/3 as an Open System
R/3 um sistema aberto que permite a comunicao com vrias outras plataformas, quer seja entre as instncias de um sistema R/3 ou com outros sistemas R/3, R/2 ou sistemas no SAP atravs de rede. A Comunicao em rede pode ser dividida em 7 camadas, onde cada camada serve de interface entre a camada de baixo e camada de cima. Do ponto de vista da programao, desenvolver uma comunicao entre sistemas mais fcil a medida que esta conversa implementada nas camadas mais superiores. A SAP suporta os protocolos TCP/IP e SNA LU6.2. A comunicao entre sistemas R/3 se d em TCP/IP e a comunicao LU6.2 utilizada para a comunicao com sistemas R/2 baseados em mainframe. A programao R/3 suporta ainda CPI-C, RFC e OLE Automation como interfaces de comunicao. Os dois primeiros protocolos so proprietrios da SAP e o OLE um protocolo da Microsoft para a comunicao entre aplicativos na plataforma windows

R/3 Gateway Service

SAP Gateway o CPI-C handler, responsvel pela conexo entre os protocolos TCP/IP e LU6.2, utilizado para a conexo entre sistemas R/3 e sistemas R/2 baseados em mainframe. O Gateway pode rodar tanto em um application server quanto em um database server. Pequenas mensagens, como visto anteriormente, fluem entre os application e a central instance em um sistema R/3 atravs do message server. J os volumes mais elevados de dados, tais como os dados da aplicao fluem

Com isto podemos ver que a comunicao atravs do gateway tanto pode se dar dentro de um sistema R/3 quanto entre um sistema R/3 e um sistema R/2 ou com programas externos. O gateway utiliza o protocolo TCP/IP, atravs de RFC, para comunicao com os clients e LU6.2 apenas para a

Communication with CPI-C

CPI-C um protocolo utilizado para a comunicao elementar program-to-program. utilizada basicamente para a comunicao entre sistemas R/2 e outros aplicativos mainframe. a implementao SAP da LU6.2. A comunicao faz uso dos verbos bsicos da comunicao LU6.2 (INIT, ALLOCATE, ACCEPT, SEND, RECEIVE e DEALLOCATE). Como no padro IBM, um protocolo de comunicao que exige que enquanto um parceiro esteja transmitindo o outro se encontre em modo de escuta, e vice versa (sempre funciona na modalidade sincrona). Lembrar que se for o caso de estabelecer uma conexo com ambiente IBM ser necessrio usar funes feitas pela SAP para converter o conjunto de caracter de ascii para ebcdic. Os parmetros enviados pelo comando INIT so definidos atravs da tabela TXCOM e mantidos

Remote Function Call

RFC uma interface de comunicao baseada em CPI-C mas que possui mais funes alm de ser mais simples de se utilizar. Pode ser utilizada para a comunicao entre sistemas R/3, R/3 com R/2 bem como aplicaes externas. O RFC permite a chamada de subrotinas remotamente pela rede. Estas subrotinas so chamadas de function modules. Estas funes possuem parmetros e retornam valores como qualquer outra funo e so gerenciadas dentro do R/3 atravs de sua prpria function library, denominada Function Builder.

13

Function Builder (transao SE37) d ao programador uma excelente ferramenta para programar, documentar e testar as function modules, que tanto podem ser chamadas em modo local quanto remotamente. O Sistema R/3 gera automaticamente todo o protocolo necessrio para a comunicao RFC entre os sistemas. Os requerimentos para o RFC so os mesmos para o CPI-C. Os parmetros para a comunicao RFC so mantidos travs da transao SM59. O R/3 vem ainda acompanhado de uma biblioteca de funes C para comunicao externa via RFC com o R/3, o RFC-SDK (Software Development System), sendo que o que diferencia uma chamada RFC local de uma remota apenas o parmetro (destination) que especifica onde o comando ser executado chamadas RFC : Synchronous RFC call, onde o programa que emitiu a chamada suspende a execuo at o retorno da chamada Asynchronous RFC call, onde a funo chamada roda em paralelo e independente do programa que emitiu o comando. O programador fica responsvel pela conexo lgica dos resultados obtidos Transactional RFC call, onde vrias funes so agrupadas em uma nica transao que executada no sistema remoto como uma nica LUW na seqncia com que elas foram codificadas. Caso ocorra um erro, o sistema que emitiu o comando recebe um cdigo de retorno que pode ser consultado pela transao SM58. Ainda neste caso o sistema destino no precisa estar disponvel no momento em que o comando emitido, podendo ainda ser parametrizado o intervalo entre os queries.

Business Objects and BAPIs

Os business objects formam a base para a comunicao em alto nvel no sistema R/3, tornando possvel por exemplo implementaes R/3 na internet e tem as seguintes caractersticas: Formam a base para uma bem sucedida comunicao em sistemas client/servers So orientados ao negcio. Existem BAPIs chamados Customer, Order, etc. Possui mtodos, que so os business functions que facilitam e padronizam a utilizao destes objetos So gerenciados internamente pelo R/3 em uma biblioteca central, a Business Object Repository, ou BOR As BAPIs (Business Application Programming Interfaces) so interfaces funcionais que utilizam business methods para executar funes de negcio. Elas podem ser chamadas tanto pelos programas R/3 quanto encapsuladas e instnciadas por programas externos.

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

OLE (Object Linking and Embedding) uma forma de comunicao entre programas orientada para objeto. Com isto possvel conectar aplicaes desktop que utilizam OLE2 (Word, Excell, etc.) com o sistema R/3. Quando o sistema R/3 est agindo como um client OLE, o usurio chama o programa (word, excell) de dentro do programa ABAP. Os comandos OLE so transferidos para o PC

Os objetos OLE aos quais o R/3 pode se conectar como client so definidos internamente no R/3 (atravs de type informations) onde se definem os mtodos, atributos e parmetros do objeto. A (CREATE OBJECT, CALL METHOD, GET/SET PROPERTY e FREE OBJECT) que permitem instnciar e manipular o objeto. Quando o R/3 funciona como um OLE server, suas funes podem ser chamadas de dentro das aplicaes que rodam no desktop. Estas chamadas so enviadas ao SAP Automation Server que converte os calls para RFCs que so enviados ao sistema R/3. Estas chamadas ativam BAPIs ou function modules dentro do sistema R/3 que processam as informaes que so ento enviadas de volta para o Automation Server que a repassa para o aplicativo no desktop. Do ponto de vista da programao, usurios podem utilizar as function modules do R/3 em uma programao orientada para objeto, como por exemplo utilizando C++ ou Visual Basic. Isto vlido

14

para todos os objetos que so gerenciados centralizadamente pelo R/3 atravs da BOR (Business Object Repository). Como os BOR e function modules se encontram no R/3, para utiliza-los necessrio 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 de vista do R/3, o A Gate age como um usurio comum, uma vez que o IST converte toda a conversa com o sistema para protocolos utilizados pelo SAPGUI. O A Gate mescla os dados recebidos com templates HTML e os envia atravs do W Gate para o HTTP server, onde so finalmente exibidos para o usurio atravs dos browsers padro (explorer ou netscape). A SAP fornece o IAC (Internet Application Component) que possui Web Transactions que nada mais so que mapeamentos Web de transaes standard R/3. Assim como qualquer pgina HTML, o usurio pode customizar o lay out de acordo com suas necessidades. Para permitir uma boa performance a SAP est rescrevendo algumas transaes para que essas funcionem de forma integrada com a internet.

EDI Architecture
Electronic Data Interchange uma forma estruturada e eletrnica para trocar informaes entre diversos sistemas. Esta arquitetura tem as seguintes caractersticas: EDI-enabled applications, que permite que transaes de negcio sejam processadas automaticamente A interface IDOC, que foi criada como uma interface aberta e consiste de documentos intermedirios e seus respectivos function modules subsystem EDI, que converte os documentos intermedirios em mensagens EDI e vice versa. O SAP no implementa esta facilidade O componente principal desta interface o Idoc, que um SAP standard que especifica a estrutura e o formato do dado que est sendo transferido.

Distribution of Business Processes with ALE

Por razes tcnicas ou de negcio pode ser necessrio fazer uma implementao descentralizada do R/3. O conceito ALE (Application Link Enabling) permite configurar e operar aplicaes distribudas em SAP. ALE consiste de uma troca controlada de mensagens de negcio, mais especificamente os dados do negcio, que permitem a integrao consistente de sistemas distribudos. Os aplicativos so integrados atravs de comunicaes tanto sncronas quanto assncronas e por TRFC (transactional RFC). Para especificar um sistema distribudo necessrio especificar o modelo lgico de distribuio de dados para definir em que sistema rodar e ainda entre quais e como os dados devero ser intercambiados. Os dados tambm so transferidos atravs de Idocs (Intermediate Documents) para possveis aplicaes de EDI.

Data Transfer and Batch Input

Quando se transfere dados entre sistemas R/3 ou entre o legado e o R/3, importante garantir que estes dados entrem de forma consistente dentro do sistema destino. Desde que se utilize as mesmas transaes conversacionais utilizadas pelos usurios para entrar com os dados no sistema, fica assegurado que os dados passaro pelas mesmas consistncias que se efetuam nas entradas

O mtodo comumente utilizado para entrada de dados do legado conhecido como batch input.

15

R/3 Graphical User Interface

Frontend Administration
Usurios no necessitam da mesma configurao em seus PCs, embora uma workstation simplifica o trabalho de administrao. Considere a facilidade e a dificuldade para atualizar os softwares da estao Frontend Requirements: A nota 86895 descreve detalhadamente a configurao da estao Configurao Mnima Item Processador 486 RAM 16MB Net connection Winsocket API Configurao para Windows NT Item Configurao Mnima Processador Pentium 90 RAM 32MB Net connection TCP/IP Configurao desejvel Pentium 133 32MB Winsock.dll Configurao desejvel Pentium 133 48MB TCP/IP

Para testar o funcionamento da rede entre a estao e o host basta efetuar um ping ou telnet. As configuraes 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 verso do SAPGUI necessrio deletar a verso anterior. O programa sappurge.exe pode ser utilizado para esta finalidade. A instalao feita individualmente em cada PC. Programe a melhor forma para otimizar o trabalho. O arquivo SAPSETUP.INI pode ser editado para parametrizar a instalao. Nele se configura quais os componentes a serem instalados e O sapsetup.exe permite uma instalao dialog free startada a partir da linha de comando (veja o R/3 Installation Guide) o que assegura uma distribuio automtica do software e a manuteno do frontend utilizando logon scripts. A vantagem neste tipo de instalao que a configurao das estaes feita a partir de uma localizao central atravs de um logon script, que faz todas as checagens necessrias (hardware e network) e executa as operaes necessrias para instalar e manter o frontend. A desvantagem deste mtodo que se tem mais trabalho para implementar o check de verso no logon script e para analisar os resultados da instalao no arquivo sapsetup.log. A SAP recomenda que sob windows 95 e NT primeiro se faa uma instalao em um servidor (installation server) utilizando o installation wizard e posteriormente se instale os clients a partir dele. O programa utilizado na instalao o \Gui\Windows\Win32\Sapsetup.exe

Types of Online Help

Existem diversos tipos de implementao do online help no R/3: PlainHtmlHelp converte documentos para HTML standard. Pode ser instalado em todas as plataformas de frontends e exibida atravs dos browsers convencionais. Pode ser utilizado tanto com Windows 95, NT ou ainda quando um Web server disponvel na instalao (intranet) PlainHtmlFile converte documentos para HTML standard. Pode ser instalado em todas as plataformas de frontends e os documentos so acessados atravs de um file server que

16

disponibiliza os dados de um diretrio por compartilhamento onde so exibidos atravs dos browsers convencionais nas estaes. Pode ser utilizado tanto com Windows 95, NT ou ainda quando um Web server disponvel na instalao (intranet) HtmlHelpFile converte documentos armazenados no formato HTML comprimido para Html convencional. Pode ser utilizado apenas em estaes Windows 95 ou NT. instalado em um file server compartilhado, como o anterior, mas sua principal vantagem que o espao necessrio 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 estao antes da instalao do SAPGUI, j que o browser que contm todos os HTML controls necessrios.

O tipo de help e sua localizao so especificados como parmetros nas profiles do R/3. A configurao do arquivo SAPDOCCD.INI no frontend sobrepe a definio genrica das profiles do R/3 e deve ser utilizada como complementao a definio do sistema central. Os parmetros importantes e relevantes para a configurao do help so o eu/iwb/help_type, o eu/iwb/installed_language e o eu/iwb/path_win32.

SAPLOGON Options e traces

O programa saplogon.exe se encontra no diretrio drive:\<target>\sapgui, conforme foi definido no momento da instalao. O saplogon utiliza o programa sapgui.exe para se conectar com o application server. O arquivo saplogon.ini configura as entradas disponveis na janela do saplogon e mantido quando se atualiza as entradas disponveis do usurio. As informaes l contidas so utilizadas para montar o string de conexo ao application server. Para evitar que o usurio edite as entradas deste

Ao se clicar no canto esquerdo da janela do saplogon possvel obter informaes about que descrevem a localizao dos dois arquivos (sapgui.exe e saplogon.ini). O boto do canto superior esquerdo da janela permite ainda que se configure as opes de trace do saplogon e as funcionalidades de edio. Estas definies ficam armazenadas na seo [Configuration] do saplogon.ini Assim como o saplogon.ini, os arquivos sapmsg.ini e saproute.ini so mantidos implicitamente quando edita as entradas do saplogon. O primeiro contm a relao dos message servers e seus respectivos servios (logical service names) que ser lido sempre que se efetua uma requisio de logon a um logon group atravs do saplogon. O segundo arquivo (saproute.msg) lista os saprouters que podem ser selecionados no saplogon. J o arquivo services do windows no editado pelo saplogon embora possua entradas fundamentais para o seu funcionamento, devendo portanto ser editado em separado. Nele so especificadas 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 de conexo depende do target escolhido: Para conexo com uma instncia R/3: sapgui /H/<appserver>/S/32nn Para conexo com um message server: sapgui /M/<host name>/S/36nn/G/<logon group> Para conexo saprouter: sapgui /H/<host1>/S/3299/H/<host2>/S/3299/H/<oss host>/S/36nn/G/Public Os nmeros dos servios podero ser substitudos pelas respectivas entradas colocadas no services: sapdp<nn> para o dispatcher e sapms<SID> para o message server. S para constar, as portas do gateway (sapgw00) so as 3300. Se for necessrio, o log de start do sapgui pode ser ativado. Ele recebera o nome dev_9999.TDW (ascii) e dev_9999.log (binrio) e sero gravados na area de work do sapgui. Eles possuem a log de tudo que aconteceu. Resumindo os arquivos ini. O saplogin.ini possui a configurao das instncias e seus respectivos system numbers. No sapmsg.ini teremos a indicao de quais so os messages de cada um dos sistema R/3. No saproute.ini teremos as strings de roteamento do R/3 e no arquivo services teremos

17

as portas que sero utilizadas pelo dispatcher, gateway, message e etc. Devemos sempre tomar cuidado ao alterar o service pois ele no segue um padro entre maquinas diferentes e principalmente com usos diferentes. Em relao a localizao dos arquivos, os sap*.ini esto no diretrio do windows e o service ou est no diretrio do win9x ou no system32/drivers/etc do winnt.

SAP MAPI and SAPGUI for java

O SAP MAPI permite a integrao dos softwares de correio eletronico e o R/3. Especificamente o MAPI permite que o ambiente de troca de mensagens do R/3, conhecido como Office, passe a ser acessado como se fosse uma pasta do Outlook ou do exchange da microsoft. Uma outra evoluo da SAP a disponibilizaro do sapgui na linguagem java. Isto, pelo menos a princpio, facilitaria a distribuio de softwares para as estaes mas ainda possui o inconveniente do ambiente ser mais complexo. Outra desvantagem a tecnologia estar no inicio do vida e portanto ainda sem contar com uma boa performance e estabilidade de ambiente. O arquivo que corresponderia ao saplogon.ini neste ambiente o IDES.html. Durante a ativao de um sapgui java devemos lembrar que at o aparecimento da janela para o identificao do template (ides.html) que identifica o servidor a ser acessado; carga das classes java que sero processadas no lado do cliente; troca de mensagens entre os servidores para a montagem da pgina atravs do orbixd (object requeste broker daemon).

Se for necessrio saber mais sobre o assunto, procure pela nota 42268 ()

18

Starting and Stoping R/3 NT Version

Operating System Tasks
Durante o startup do NT todos os servios relacionados podero ser inicializados automaticamente (desde que configurados atravs do control panel -> services). Em relao ao R/3 neste momento SAP<SID>_<SystemNumber>, SAPOSCOL e OracleService<SID> devem ser inicializado. A seqncia de inicializao no relevante pois um no depende do outro, mas para o start do R/3 todos j devem estar ativos. O SAP<SID>_<SystemNumber> o responsvel por coordenar o start/stop do message e do gateway. O usurio utilizado para inicializar o servio o SAPService<SID> com a senha informada

O SAPOSCOL o responsvel por coletar as informaes sobre os recursos do sistema operacional e suas respectivas cargas e disponibilizar estas informaes para o R/3. O usurio utilizado para inicializao tambm o SAPService<SID>. O OracleService<SID> responsvel pelo controle da instncia oracle e no necessita de usurio para ser inicializado.

Administrator Tasks
Para inicializar o R/3 devemos sempre seguir a seguinte seqncia : Os servios bsicos devem estar ativos (saposcol, sapSID_## e OracleServiceSAP) Abrir a conta SIDadm na console do NT Ativar a instncia do Oracle (pode ser feito pelo instance manager da oracle) Ativar a instncia do R/3 (pode ser feito atravs do sap service manager) O Sap Service Manager usa as cores para indicar a fase em que est cada servio, a saber : verde (processo sendo executado), vermelho (processo terminado anormalmente), amarelo (processo sendo inicializado) e branco (servio no est ativo ou com situao desconhecida)

Process Startup Sequence

Seqncia bsica do start do SAP Service Manager : Na camada de servios Verifica se os servios bsicos esto no ar (SAP<SID>_<SystemNumber> e OracleService<SID>) Aciona o SAP<SID>_<##>, que a Start Profile do sistema R/3 do qual o SIDadm o administrador e executa-a. Verifica e se necessrio executa o script strdbs.cmd de inicializao do banco de dados Verifica e se necessrio executa o script msg_server.exe que coloca no ar o message Verifica e se necessrio executa o script disp+work que coloca no ar o dispatcher Na camada de processos Com as informaes da default profile e a instance profile o dispatcher (disp+work) inicializa o R/3 criando os work process necessrios e o servio de gateway As profiles esto no compartilhamento \\<sapGlobalHost>\sapmnt\<SID>\SYS\profile conhecido tambm como \usr\sap\SID\SYS\profile (se ignorarmos o disco onde est a instalao). Para o acesso remoto o compartilhamento a ser utilizado ser o sapmnt, para o acesso local o compartilhamento a ser utilizado o saploc. Se for necessrio iniciar a instncia atravs da linha de comando utilize o comando startsap que tambm possui seu inverso, o stopsap.

19

Parameter Read Sequence

A seqncia para a leitura dos parmetros a seguinte : NT register Ambiente do NT Declaradas no start profile Default profile Instance profile O valor que ser utilizado ser o que aparecer por ultimo nesta lista. Para certificar qual o valor assumido para um determinado parmetro utilize o relatrio RSPFPAR. Resumindo, o SAP service l as variveis de ambiente, a start profile e a default profile; o R/3 kernel (conhecido com dispatcher) l a default e a instance profile. Se algum parmetro for alterado, para ele passar a valer, tudo que for afetado deve ser reinicializado.

Logs and Traces Logs and Traces for Database Startup

Para saber o que aconteceu durante o startup do banco, alm de erros e eventos do sistema, procure pela log <drive:>\oracle\SID\saptrace\background\<SID>ALRT.LOG. Esta log conhecida com database alert file. Maiores detalhes sobre erros procure por <drive:>\oracle\SID\saptrace \usertrace\ora<####>.trc, que tambm conhecido como oracle trace information. Em relao ao sapdba, as logs ficam nos diretrios sapcheck, sapreorg e sapbackup.

Startup logs and traces in Windows NT

Todas as mensagens geradas pelos servios, SAP server manager ou outra aplicao do NT so logadas no Event Viewer (utilizar o caminho Menu iniciar, programas, aplicao administrative tools (common), event viewer eventvwr) nas logs de sistema, de aplicao e de segurana.

Startup logs and traces in R/3

O diretrio de work contm todos os arquivos de trace e de mensagens de erros da instncia R/3.. Arquivos de erros gravados pelo executvel sapntstartb.exe que acionado pelo SAP service manager ou pelo startsap : Stderr1 contm as logs do banco de dados Stderr2 contm as logs do message server Stderr3 contm as logs do dispatcher Sapstart.trc contm o trace do programa sapntstartb. Vale lembrar que o nvel do trace a ser logado pode ser alterado pelo parmetro rdisp/trace e este varia de 0 (no trace) at 3 (todas as mensagens e trace completo) Arquivos de trace : Sapstart.log contm, de forma um pouco menos detalhada, a toda a log da inicializao Dev_ms contm o trace do message server Dev_disp contm o trace do dispatcher Dev_w0 n contm o trace de um work process especifico Uma boa transao para ver as logs a transao RZ03 e menu utility. Outra boa transao para ver mensagens de log a SM21, mas esta mostra as mensagens de log de R/3.

Startup Diagnostics
As principais razes de falha durante o processo de inicializao so : SAP Service Manager no consegue conectar com o SAP service. Normalmente ou ele no est ativo ou no esta configurado corretamente.

20

SAP service no inicia. Ou as entradas no NT register esto erradas, ou tem algum problema de configurao ou a senha est errada Database no inicia. Verifique as variveis de ambiente, se o db est em dba mode, se algum arquivo foi perdido ou corrompido ou se o listener est desativado R/3 no inicia. Pode ser os compartilhamentos de disco, a configurao do servio (por exemplo, usurio errado ou sem autorizao), problemas de permisso nos arquivos, erro de tcp (host, services, dns, etc) ou erro na conexo com o database.

Reasons for R/3 Downtime

Eventualmente podemos parar o sistema para alterar a configurao e parametrizao, para manuteno 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 no podem estar prximos de disparar jobs no R/3, via sapevt ou rfc Nenhuma atualizao est em andamento. Para isso use a SM13; Nenhum usurio est trabalhando no sistema. Para isso use a SM04; No existe atividade para o gateway. Para isso use a SMGW. bastante conveniente enviar mensagem para os usurios do que ser feito. Para isso use a SM02.

Stopping the R/3 system

Para parar uma instncia R/3 podemos faze-lo atravs do CCMS (que na verdade a transao SRZL) ou pelo SAP Service Manager (neste caso ele manda uma mensagem pelo named pipe para a instncia). A grande diferena do NT para o Unix que o stopsap no para o banco de dados, ou seja, a pesar do startsap inicializar o banco de dados o stopsap no o paralisa. Para o banco de dados podemos utilizar o sapdba ou alguma ferramenta do oracle, como Oracle Instance Manager ou o Oracle Server Manager

Database Error Stopping

Eventualmente, durante a paralisao do R/3 e do oracle, o oracle no consegue parar. Isto pode ocorrer por que o banco de dados ainda est trabalhando na realizao do rollback, ou porque um backup online est sendo tirado, ou porque a rea de archive est cheia. Normalmente este ultimo motivo (archive cheia) o grande motivo de travamento do R/3 e a nica soluo para o problema o

Backup off-line: database reconnect

Quando do backup off-line o R/3 pode ser configurado para no ser paralisado junto com o banco de dados. Isto feito atravs dos parmetros rsdb/reco_trials e rsdb/reco_sleep_time que configuram a quantidade de tentativas de recuperar a conexo e o tempo de espera por esta conexo. Com isto conseguimos que os buffers sejam preservados e as aplicaes que estavam sendo executadas naquele momento no so abortadas. Na prtica esta poltica est associada a backups com recursos de split mirrow de discos que contm os arquivos de dados do oracle.

21

Starting and Stoping R/3 Unix Version

Operating System Tasks
O usurio <sid>adm utilizado para administrao do sistema R/3. O start do R/3 efetuado startsap_<host>_<instance nbr>, que fica no diretrio home do usurio. Este script tem um alias: startsap. O startsap verifica se o processo saposcol est rodando e o ativa, se necessrio. O scipt pode ainda chamar o script startdb caso o banco se encontre em shut down. Em seguida o script starta a instncia R/3. O script aceita 3 tipos de parmetros: startsap R3, ativa apenas a instncia R/3, desde que o banco esteja rodando startsap DB, ativa apenas o banco de dados startsap all, ativa o banco e a instncia ( o default quando nenhum parmetro especificado Um sistema R/3 possui basicamente 3 profiles que se encontram no diretrio /usr/sap/<SID>/SYS/profile: Start profile: START_<instance>_<host>, que contm a relao dos componentes que sero ativados pelo sapstart na instncia Default profile: DEFAULT.PFL, que contm alguns parmetros globais do sistema Instance profile: <SID>_<instance>_<host>, que contm parmetros especficos 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 servios disponveis na instncia 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 sero ativados. Os processos sender e collector so 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 so criados de acordo com as informaes da instance e da default profile. O gateway reader independe de parmetros 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 diretrio de work um arquivo kill.sap que contm o comando kill <sapstart process nbr>, que ser executado pelo script de stop da instncia. Para garantir um start consistente, a seqncia dos parmetros lidos pelos work processes seguem um padro definido, conhecido como parameter replace sequence: So lidos os parmetros hard coded nos fontes C do kernel Parmetros contidos na default profile sobrescrevem valores ja lidos no step anterior Parmetros da instance profile sobrescrevem os anteriores kernel do R/3 (disp+work) l os parmetros contidos nas default e instance profiles. Desta forma, alteraes nelas executadas somente tero validade no prximo start.

Database Startup and Logs

Durante o processo de start, quando requerido, o startsap chama o script startdb que grava uma log apropriada no startdb.log. Eventos significantes (start, stop, errors) so logados pelo no Oracle alert file: /oracle/<SID>/saptrace/background/alert_<SID>_.log. Informaes detalhadas de erro so logadas no Oracle trace file: /oracle/<SID>/usertrace/ora_<pid>.trc. Quando se utiliza o sapdba para start e stop do banco de dados, o sapdba grava uma log no diretrio /oracle/<SID>/sapreorg, .../sapcheck, .../sapbackup, dependendo da ao que foi executada

R/3 Startup and Logs

O script startsap grava uma log de start no diretrio home do usurio <sid>adm. O diretrio de work contm trace files e error files de mensagens relacionadas com o start dos work processes e

22

demais servios. O nvel de informaes gravadas nos trace files definido pelo parmetro rdisp/TRACE da instance profile. O default 1 (errors e warnings), aceitando valores 0, 1, 2 e 3. O correto acompanhamento das logs permite identificar o ponto onde ocorreu um erro no processo de start de uma instncia R/3

Stopping R/3 Systems

As razes para se parar uma instncia R/3 vo desde paradas planejadas (mudana na profile, manuteno do sistema R/3 ou DB, upgrades) at quedas no planejadas, por exemplo por falha de hardware. Antes de parar um sistema R/3 convm verificar os seguintes pontos no sistema. Havendo Verifique jobs background e batch input (SM37) Estado da fila de update (SM13) Informe os usurios (SM02) Verifique os usurios logados (SM04, AL08) Verifique interfaces externas

A parada do sistema dever ocorrer primeiro nos dialog instances e posteriormente na central instance e database. O comando utilizado o stopsap (alias do script stopsap_<host>_<nbr>) que possui basicamente os mesmos parmetros e funcionalidades do startsap (R3, DB, all). A parada apenas do database (stopsap db ou sapdba) faz com que os work processes do R/3 interrompam a conexo com o Oracle. Estes processos tentaro uma reconexo (parametrizada por profile) e em caso de insucesso, entraro em modo de reconnect e somente tentaro nova conexo sob demanda. O processo de retirar apenas o database poder ser uma opo para efetuar o backup offline do banco de dados preservando porm os buffers da instncia R/3 intactos durante o processo. Erros durante a tentativa de parada do database podero ocorrer erros caso o Oracle esteja efetuando um rollback, executando um online backup ou ainda por se encontrar travado devido a falta de rea para o archive. Caso a causa no possa ser identificada facilmente, utilize a SM21 para tentar identificar possveis mensagens. De qualquer forma, elimine a causa antes de fazer novas tentativas de shutdown.

23

CCMS Configuration
Overview
O Computing Center Management System, conhecido como CCMS e acionado pela transao SRZL, a ferramenta que prove o gerenciamento de : Performance, monitorao e anlise do R/3, sistema operacional e rede Profiles, modos de operao e logon groups Start/stop dos ambientes Banco de dados e do archiving do banco de dados; Carga de trabalho (workload) Impresses Segurana 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 disponvel para processamento Definir os modos de operao do sistema. Normalmente definimos dois (diurno e noturno) para balancear e distribuir a carga segundo o perfil de utilizao de cada horrio Criar as definies dos perfis das instncias com os seus respectivos parmetros de Associar cada um destes perfis aos modos de operaes Definir a tabela de horrios de entrada e sada de cada um destes perfis definidos no modo de

RZ10: Profile Maintenance

Esta a ferramenta para manuteno das diversas profiles do R/3 (start, default e instance). Com ela podemos editar e manter todos os parmetros. A manuteno pode ser feita de forma bsica ou estendida, o que difere se os parmetros sero manipulados de forma individual ou de forma coletiva. A transao ainda permite deletar, comparar e verificar as profiles e suas diferentes verses. Lembrando, as profiles seguem o seguinte padro de nome : Start : START_DVEBMGS00_hostname Default : DEFAULT.PFL Instance : SID_DVEBMGS00_hostname Os passos para a manuteno inicial das profiles so : Importa-las a partir do sistema operacional; Mante-las utilizando a RZ10; salva-las e ativa-las. Tomar cuidado com o boto import pois ele importa apenas o servidor corrente. Para importar use o menu Utilities, Import profiles, of active servers.

R/3 Profiles
A incorreta configurao do CCMS no impede o funcionamento do R/3, porm impede que o CCMS exiba dados teis. A transao RZ10 do CCMS permite que se d manuteno nas profiles das instncias do R/3. Ela mantm os parmetros na base de dados do R/3 e a cada alterao efetuada uma nova verso gerada nesta base de dados. Quando ativamos uma verso de profile atravs desta interface, seus parmetros so copiados e transferidos para a profile ativa, que fica em diretrio prprio do sistema operacional. Desta forma a base de dados do R/3 pode conter vrias verses de uma mesma profile, um histrico das alteraes alm de documentao dos parmetros. Em ambientes distribudos com vrias instncias R/3, o diretrio de profiles compartilhado entre todas as instncias e permanece como repositrio central de todas as profiles. Para cada sistema R/3 existem vrias profiles. Uma DEFAULT profile e, para cada instncia do ambiente, uma instance e uma start profile. Atravs da ferramenta RZ10, existem dois modos de exibio/edio das profiles:

24

Em basic mode, os parmetros que so alterados mais freqentemente so agrupados de acordo com suas interdependncias de modo que a alterao em um deles se reflita automaticamente nos demais. Nesta interface basic os parmetros aparecem sem os seus nomes tcnicos, mas apenas como campos em screen. Em extended mode, os parmetros aparecem e so editados em uma interface tipo editor de texto, onde cada parmetro listado com o seu nome tcnico e respectivo valor. O administrador aqui dever conhecer os seus nomes tcnicos e claro suas interdependncias.

O programa de instalao, R3SETUP, cria a primeira verso das profiles no sistema operacional de acordo com os recursos do sistema (memria e CPU). Durante o processo de configurao inicial do CCMS, importamos estas profiles para a base de dados R/3 utilizando a RZ10 e efetuamos as nossas customizaes. Isto permite uma gerncia centralizada de todas as profiles de um ambiente. As profiles utilizadas pelo R/3 para configurao da instncia durante o startup sempre a profile ativa, ou seja, aquela que se encontra copiada no sistema operacional. A partir do momento que importamos as profiles pela RZ10, todas as manutenes sempre devero se dar atravs desta interface nunca diretamente no sistema operacional para evitar que haja dessincronizao das ferramentas. Qualquer dvida quanto ao sincronismo poder ser verificado atravs de seus mecanismos de check e da comparao de verses. Do ponto de vista do R/3, uma profile consiste de duas partes lgicas: entradas nas tabelas da base de dados do R/3 e um arquivo no sistema operacional. Como a verso utilizada pelo startup a do OS (profile ativa), alteraes efetuadas nos parmetros devero ser salvas no sistema operacional e somente tero efeito no prximo start da instncia. Somente a verso mais recente de uma profile pode ser ativada pela ferramenta RZ10. Na prtica isto significa que a tentativa de ativar uma verso mais antiga faz com que a profile seja copiada com uma nova verso e ativada. Qualquer manuteno vai sempre gerando novas verses na base de dados que ficam documentadas como comentrios e headers no file do sistema operacional. Dynamic Switching na RZ10. O procedimento de check de profiles oferece vrios mecanismos de aferio de suas integridades: Comparar a profile da base de dados com a profile ativa no sistema operacional Verificar a sintaxe dos parmetros codificados Verificar se os valores especificados nos parmetros so vlidos ou ainda se no esto muito discrepantes (por exemplo 10 vezes maior que o default, etc.) Efetuar comparaes entre todas as profiles definidas para encontrar inconsistncias de definio. Com isto possvel encontrar erros na definio de mais de um message server, por exemplo. sistema efetua um check automtico de consistncia entre a profile ativa e a base de dados sempre que efetua um startup. Caso encontre alguma discrepncia um alert ativado no Alert Monitor

Operation Modes
Operation mode uma facilidade do R/3 que permite que se configure diferentes combinaes nos tipos de work processes que podem ser ativados ao longo do dia sem a necessidade de stop/start da instncia. Isto permite que possamos ter por exemplo uma maior disponibilizao de background work processes durante perodos de maior demanda desta funcionalidade, como perodos noturnos. J os perodos diurnos so caracterizados por uma demanda muito maior de processamento dialog. Operation mode permite portanto maximizar a utilizao dos recursos do sistema sem a necessidade de stop/start das instncias para que as configuraes tomem efeito. Uma configurao bsica de operation mode especifica os servios ou tipos dos work processes e os perodos escolhidos para cada intervalo. atravs desta funcionalidade que conseguimos configurar background work processes para processamento exclusivo de jobs classe A. Operation mode pode ser configurado baseado em alguns conceitos bsicos: nmero total de work processes deve permanecer o mesmo entre os operation modes de uma instncia, j que nenhum novo servio ser startado, apenas os processos tero suas funcionalidades reconfiguradas.

25

Cada instncia dever permanecer com o requisito mnimo de dois dialog processes Cada sistema dever permanecer com um processo de enqueue e pelo menos um update.

RZ10, atravs de seus mecanismos de check, oferece recursos para efetuar estas verificaes das profiles e dos operation modes configurados. A mudana de configurao entre operation modes pode ocorrer manualmente sob demanda do administrador do sistema atravs da RZ04 ou ento de forma automtica atravs da definio de um schedule de horrios chamado de timetable, que configura um ciclo completo de 24 horas. Este schedule de horrios mantido atravs SM63. A timetable nica para todas as instncias de um sistema. Isto significa que todas devero possuir a mesma configurao de operation modes, porm cada uma poder ter a sua configurao individual de work processes. Alm da timetable normal que configura o ciclo de 24 horas do operation mode, possvel definir uma timetable excepcional para ser ativada em uma data especfica. Enquanto uma timetable normal deve possuir entradas que cobrem todas as 24 horas do dia, uma timetable excepcional poder possuir entradas apenas para um determinado perodo do dia. Nos demais perodos continuariam

Quando a mudana entre modos de operao ocorre, os work processes so distribudos automaticamente, sem necessidade de parada e restart das instncias. Nenhum tempo perdido por indisponibilidade do sistema, apenas o tipo dos work processes alterado, permanecendo porm o

possvel simular o switch de um operation mode em test mode e desta forma analisar possveis falhas atravs da log de switch. Discrepncias existentes na configurao das profiles ou na definio dos operation mode podero ser identificadas e eliminadas.

Starting and Stopping Instances with the CCMS

Atravs do CCMS, transao RZ03, possvel startar e parar as instncias R/3 de um sistema. A instncia de banco de dados e pelo menos uma instncia do ambiente precisam porm ter sido startadas atravs das ferramentas do sistema operacional. Em plataformas UNIX utilizada a facilidade de rexec para esta operao remota. J no NT esta facilidade (rexec) no padro e deve ser startada se precisarmos que uma instncia NT manipule uma instncia Unix. Alm de permitir a parada de uma instncia a RZ03 tambm permite o switch de operation mode manualmente.

26

Background Processing
Background Concepts and Features
Um job background um ou mais programas ABAB, external programs ou external commands que rodam seqencialmente (steps) sem a interveno do usurio, baseados em eventos (event-based) ou horrios (time-based) pr estabelecidos. So utilizados principalmente para: Processar automaticamente tarefas rotineiras Processar informaes vindas de sistemas legados Processar tarefas baseado na ocorrncia de determinados eventos Processar uma carga em massa no ambiente em horrios de baixa atividade online Podem ser schedulados para serem disparados baseados em determinados eventos que ocorram tanto dentro quanto fora do R/3 (event-based jobs). Podem ser arranjados em classes (A, B ou C) que possuem uma hierarquia de prioridade na execuo. O sistema permite que se reserve work process livres para execuo exclusiva de jobs classe A. O mecanismo de funcionamento o seguinte: pelo menos x (configurado pela RZ04) work processes ficam reservados para classe A independente de quais sero eles. Os jobs so disparados atravs de um servio, o batch scheduler, que roda no sistema R/3. Este servio um programa ABAP que roda em um dialog work process no servidor parametrizado nas profiles do ambiente atravs do parmetro rdisp/bcttime. Neste parmetro especificado o tempo em segundos com que este programa roda, normalmente 60 segundos. Quando se especifica um valor igual a 0, o batch scheduler fica inibido naquele server. Um outro parmetro, o rdisp/bctname, define o nome do server onde os events sero checados para o disparo de jobs atravs desta facilidade, os event-based jobs. A definio de quantos batch work process estaro disponveis, sem levar em conta o modo de operao, est no parmetro rdisp/wp_no_btc. Por definio um sistema R/3 deve ter pelo menos 2 batch work process, independente de qual instncia eles vo estar, para atender o sistema de transporte. Se o sistema R/3 no for trabalhar com transportes no necessrio ter batch work process (mas isto meio absurdo se pensarmos no dia-a-dia prtico). O mecanismo do batch scheduler, aps a ativao, segue o seguintes passos : Verifica a job-scheduling table ordenado por data de start, classe, servidor de destino e data da criao do job; Se o job for para ser executado na prpria instncia o dispatcher acionado para alocar um BTC, se o job for para ser executado em qualquer instncia o message acionado para determinar qual o servidor com menor carga.

Operation Modes and Scheduling

O sistema efetua balanceamento de carga automtica entre os servidores, a menos que se especifique o server target do job. A especificao do server durante o schedule faz com que o job tenha prioridade sobre outros da mesma classe sem a especificao explcita do server. possvel configurar operation modes (atravs da transao RZ04) para efetuar um switch entre work processes de dialog e batch em horrios pr determinados sem a necessidade de um stop/start do R/3 para reconfigurao dos work processes A gerncia dos jobs feita a partir do CCMS e os jobs so schedulados a partir da transao SM36. Ao efetuar o schedule do job possvel especificar o nome de quem ir receber o spool request (opo Spool list recipient) que tanto pode ser um usurio R/3 quanto um mail do SAPOffice ou mail externo. Os Programas ABAP que requerem um determinada entrada de dados para execuo podero ser schedulados em background bastando que se informe uma variant (lista de parmetros) para processamento. Eventualmente o schedule pode ser acessado pela transao RZ01 que um visualizador grfico dos jobs que esto schedulados. Quando um job background executa comandos ou programas externos, o R/3 starta o programa server SAPXPG no host target atravs de chamadas RFC. Programas externos somente podem ser executados por usurios com autorizao para background administrator. Comandos externos podem

27

ser executados por usurios com autorizaes R/3 apropriadas. Os programas externos somente rodam em modo sncrono e os comandos externos rodam tanto em modo sncrono quanto assncrono, dependendo das necessidades do usurio. Os jobs podem ser schedulados para rodar de diferentes maneiras: Imediatamente, Com data e hora programada, Aps a ocorrncia de um evento Aps a execuo de um outro job Em um modo de operao especifica Com periodicidade, etc

Events in Job Scheduling

Os eventos com que os jobs podero estar dependentes so eventos internos do R/3 (system start, opmode switch, etc) ou eventos definidos pelo usurio, como por exemplo o trmino de uma transferncia de dados Atravs da transao SM62 podemos definir os user events e a transao SM64 utilizada para disparar os eventos. O programa sapevt (Unix ou NT) utilizado para disparar um determinado evento a partir de uma linha de comando no sistema operacional. A sintaxe do comando SAPEVT <event> [-p <parameter>] [-t] [pf=<profile_path>] [name=<SID>] [nr=<instance]. O sapevt se conecta ao message server da instncia via tcp/ip para disparar o trigger no R/3. Internamente em um programa ABAP possvel ainda disparar um evento a partir da ,a BP_EVENT_RAISE. Da mesma forma que o R/3 utiliza o SAPXPG para startar programas no sistema operacional o SAPEVT tambm utiliza o SAPXPG para startar eventos no R/3. Com isto possvel concatenar os steps 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 atravs da SM37. Estas alteraes podero ser desde a incluso de novos steps quanto a alterao de seu scheduling. Uma alterao tpica a classe de submisso, por exemplo para alterar a fila de prioridades. Jobs que esto rodando ou que j foram processados no podem ser alterado. Os jobs que esto rodando podem ser capturados, ou seja, debugados e eventualmente cancelados. Os jobs que j terminaram,

Job Monitoring
Atravs da SM37 se monitora tanto os jobs que j rodaram quanto aqueles que se encontram schedulados. O job log pode ser pesquisado para verificar as mensagens do sistema para aquela execuo. A Spool list exibe a sada da execuo. A lista exibida na SM37 depende dos critrios marcados na tela inicial. necessrio uma especial ateno para a seleo dos jobs que no possuem uma data de start e para aqueles que dependem de algum evento (colocar * no evento e clicar nas opes de jobs sem data e com predecessores). Outro ponto a ser observado a diferena entre um job released e um job ready. O released j pode ser rodado, em funo da marcao do horrio e das autorizaes, mas no est na hora de ser executado. O ready j pode ser rodado mas ainda no foi atribudo para o work process que est disponvel (provavelmente o dispatcher est muito ocupado). De qualquer forma o tempo na situao de ready mnimo.

28

Para ver os jobs existe tambm o Job Scheduling Monitor (RZ01) que exibe em modo grfico o schedule nos vrios servidores que compem o sistema ao longo do tempo. Esta transao tambm pode ser ativada a partir do Control/Monitoring do CCMS.

Job API, XBP-API and XMI-API

Atravs de programas ABAP possvel gerenciar e schedular jobs utilizando o Job Application Programming Interface, ou Job API. Atravs do Job API possvel por exemplo rodar jobs seqencialmente ou ainda incorporar lgica de deciso no ambiente de processamento ( O R/3 no consegue tratar schedule de jobs muito complexos. Um exemplo disto um job que precisaria de dois predecessores). As funes ABAP para o Job API se encontram no ABAP workbench com o nome BP_*. O XMI ou External Monitoring Interface um conjunto de mdulos de funes que agregam todas as funcionalidades para interface externas de gerenciamento do CCMS O XBP ou External Interface for Background Processing a interface externa para backgroundjob-scheduling. Estes mdulos possuem o nome comum SXMI_* e no devem ser confundidos com os Job APIs. Ferramentas externas de job scheduling (XBP) permitem que se integre em um nico ambiente o gerenciamento do schedule de jobs R/3 e no R/3 atravs de uma nica interface

Authorization for Background Jobs

A utilizao do job scheduling exige perfis especiais de autorizao para as funes de schedule e administrao. Os objetos de autorizao envolvidos so: S_BTCH_ADM que d as autorizaes para as funes administrativas. O usurio com esta autorizao com field setado para Y pode administrar jobs em todos os clients do sistema e no apenas do client onde ele est definido. S_BTCH_NAM d aos usurios a autorizao necessria para executar jobs em background. S_BTCH_JOB: este objeto possui funes que do aos usurios diversas facilidades na administrao de seus jobs e de outros usurios (DELE, LIST, PROT, RELE, PLAN e SHOW) S_ADMI_FCD: funes 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 autorizao envolvidos so: S_RZL_ADM que atravs de seus activity codes d autorizao para administrao do CCMS (01 equivale a all e 03 a display) S_LOG_COM que possui fields que autorizam a execuo de external commands S_TCODE que d autorizao para as transaes SM49 e SM69

Authorization for External Management Interfaces

Os objetos de autorizao envolvidos so: S_XMI_PROD define atravs de seus fields quais interfaces XMI e quais ferramentas externas S_XMI_LOG define se o usurio 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 no aparecer verifique os flags (aguardar o retorno)

29

System Monitoring
What, why, who and when
Os principais focos de monitorao so : R/3 (application servers, buffers, ) Database (performance, buffers, backups, ) Operationg system (cpu, file system, hardware contention, ) A monitorao no R/3 4.0 feita de uma forma simplificada atravs de uma grande arvore que ira mostrar, atravs de suas folhas, os diversos item que devemos estar atentos em todo o ambiente. A grande vantagem desta arvore a hierarquizao e categorizao de todos os elementos (tree elements e objects) que so relevantes, seus parmetros de valores (Attributes) e a captura automtica e centralizada de todas as informaes e um ponto de acesso unico para a tarefa de

Monitoring Architecture
O Alert Monitor uma ferramenta configurvel que existe no R/3 e permite a monitorao de todo o ambiente a partir de uma nica interface que exibe mensagens e sinais de alerta no sistema. A monitorao dos diversos componentes e ferramentas do ambiente R/3 uma operao necessria executada pelos administradores do sistema para melhorar a performance, garantir a disponibilidade do sistema e identificar, analisar e corrigir erros que aparecerem no ambiente. Esta monitorao uma tarefa peridica que abrange desde o sistema operacional, passando pelos componentes do kernel R/3 e indo at a base de dados do sistema. Os objetos passveis de monitorao no ambiente R/3 so arranjados em uma rvore que sumariza em seus ns as diversas reas de atuao. Esta monitoring tree agrega atributos em seus ns que podem ir sendo detalhados at chegar a granularidade mnima da entidade monitorada. Um alert identificado em um destes atributos se reflete visualmente atravs de cores (verde-ok, amarelowarning, vermelho-alert) nos ns da rvore e hierarquicamente so transferidos para os galhos mais elevados. necessrio portanto ir efetuando operaes de drill down no Alert monitor at identificar o atributo que gerou a mensagem. previsto para releases futuros do R/3 que a funcionalidade do monitor se estenda para anlise do transport system e das transaes de aplicao O monitor do R/3 concebido com uma arquitetura aberta que permite inclusive que ferramentas de terceiros sejam incorporadas a sua rvore de monitorao. Cada n da rvore denominado MTE (monitoring tree element), que podem ser agrupados em classes de monitorao. Os objetos fsicos ou lgicos que so passveis de monitorao so denominados Monitoring Objects.

Preparing the Monitor

O Alert Monitor precisa ser customizado e configurado para funcionar corretamente. Cada MTE class pode ser configurada baseado em quesitos tipo nvel de visibilidade (operador, administrador, etc.), prioridade do alerta e descries. Estas configuraes ficam vlidas para todos os objetos pertencentes a uma determinada classe, evitando assim redundncia de definies. Os atributos comuns tambm podem ser agrupados em customizing groups aos quais so associados thresholds para os alerts e textos de alerta. Uma vez configurados os alerts, possvel ento 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. Estas ferramentas tanto podero ser ferramentas standard da SAP quanto ferramentas definidas e criadas

30

pelo usurio. A rvore bsica de monitorao contm o Basic monitor, porm o usurio pode criar suas prprias rvores customizadas de monitorao.

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 (relatrio, funo, mdulo, transao, programa, etc), a localizao (servidor, banco de dados, etc) e modus operandis (background, foreground, manual) Liberar a transao 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 definio de outra arvore ou at

Monitoring and Tools

Na estrutura do Alert monitor cada server exibido separadamente. Cada server tem sua prpria rvore que contm as seguintes estruturas: Operating system, Database, R/3 services, R/3 basis system, R/3 ABAP e R/3 system log. As principais transaes e mtodos para monitorar o sistema so : A system log (transao SM21) contm informaes referentes ao sistema R/3 e suas instncias e exibe mensagens categorizadas por classes: S (R/3 start/stop/operation mode switches), W (rollback perfomed), K (kernel program error) e T (ABAP transaction error). No NT a transao mostra o log (/usr/sap/SID/dvebmgs00/log/slog00.log) apenas da instncia corrente. No Unix ela pode mostrar as logs de todas as instncias n R/3 services prov informaes sobre os work processes do sistema. A transao SM51 nos d um overview (incluindo a queue do dispatcher, system log, remote logon, etc) das instncias disponveis enquanto a SM50 analisa os work process de uma instncia especfica. A SM66 oferece um overview de todos os work processes ativos (se for necessrio o default pode ser alterado para ver todos ou em um status especifico) em todos as instncias do sistema. A SM04 e AL08 nos d um overview dos usurios logados no ambiente R/3. A SM04 mostra os usurios de uma determinada instncia e a AL08 de todas as instncias ativas. processo de update no R/3 usualmente executado em modo assncrono, onde os dados so escritos em tabelas intermedirias (VB* tables) e posteriormente transferidas para a base de dados pelos work processes de update V1 e V2. A transao SM13 permite a monitorao da fila e dos processos de update. A fila de update poder conter processos que terminaram com erro. Apesar de ser possvel em alguns casos restartar estes processos, a SAP no recomenda que se proceda ao restart da transao pelo usurio. R/3 possui seu prprio mecanismo de lock que fica residente em uma tabela na memria da instncia que contm o processo de enqueue. Os locks podem ser monitorados atravs da SM12. Os locks que permanecem no sistema podero ser eliminados manualmente aps exaustiva verificao das causas, uma vez que o procedimento normal quando os locks postados so eliminados automaticamente pelo update das tabelas ou cancelamento da A transao ST22 permite que se analise os dumps de programas ABAP. Atravs desta anlise possvel identificar o erro pela anlise dos campos e variveis envolvidos e eventualmente procurar no OSS por notas que corrijam o problema. A ST03 o workload monitor que permite analisar os tempos de resposta. As estatsticas dos tempos de resposta das transaes so apresentados de forma detalhada e estratificadas por componentes (rolltime, wait time, DB time, processing time e load time) permitindo a rpida identificao de possveis gargalos no ambiente R/3. As estatsticas apresentadas pela ST03 permanecem em um arquivo do sistema operacional (file stat no diretrio data da instncia) e so recolhidas e consolidadas de tempos em tempos pelo programa RSCOLL00 schedulado no ambiente. Este programa se baseia na tabela TCOLL para disparar uma srie de outros programas satlites que efetuam as mais diversas tarefas de consolidao por nveis de tempo/data.

31

Users and Authorization in the R/3 System

Users in the R/3 environment
O Ambiente R/3 possui vrias 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 repositrio e portanto devemos observar os aspectos de segurana nestes ambientes e na inter-relao entre o R/3 e eles. Devemos tomar cuidado com os usurios do sistema operacional (normalmente SIDadm) e do banco de dados (sys/change_on_install e system/manager) tanto na central instance quanta nos applications. Com estas chaves podemos acionar utilitrios no sistema operacional, como sapevt, e acessar o banco de dados diretamente a partir de utilitrios do oracle. Do lado do R/3 temos que ter os mesmos cuidados pois uma brecha na autorizao pode permitir que uma chave no R/3 acabe por ter acesso ao sistema operacional e aos mesmos utilitrios mencionados anteriormente. Uma das primeiras atividades aps a instalao do sistema a troca das senhas dos usurios (SIDadm, sys, system, sap, sap*, ddic e earlywatch). .

Authorization Concepts
As autorizaes existem para limitar o acesso a transaes e objetos do sistema R/3 que necessitam de proteo. As autorizaes so agrupadas em profiles e estas profiles so associadas ao master record do usurio. Autorizaes podem ser no nvel da transao ou nos mais diversos nveis, como por exemplo em operaes na transao ou ainda em range de valores de campos As autorizaes sempre pertencem a authorization objects. Estes objetos de autorizao so agrupados em object classes que por sua vez so organizados ou categorizados por business area (FI, SD, etc.). As autorizaes so mantidas atravs da especificao de valores para determinados fields dentro de cada objeto de autorizao (que pode ter at 10 fields). Todas as autorizaes so do tipo positivas, ou seja, efetuam grants para o usurio e no revokes, ou seja, se duas autorizaes forem 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 atravs da definio de activity groups PFCG) ou manualmente. Uma profile pode ainda ser composta de mais de uma profile (composite profile) mas limitada a um mximo de 150 profiles. As profiles so associadas ao usurio tanto manualmente atravs da SU01 quanto durante o processo de gerao e manuteno das activity groups. Eventualmente pode ser necessrio criar objetos de autorizaes alm do standard. Para isso usamos a transao SU21 para manter objetos de autorizaes e a SU20 para manter os campos

Em relao aos papis dos administradores de segurana no sistema poderamos dividir a administrao em trs nveis, a saber : Administrador de usurio: responsvel por manter os dados dos usurios, por associar os grupos de atividades e as profiles aos usurios e atender aos chamados dos usurios Administrador de profiles: responsvel por manter os grupos de atividades e as profiles de forma genrica sem entrar no mrito dos valores atribudos as responsabilidades e atendo-se Administrador dos dados da autorizao: responsvel por manter os valores dentro das responsabilidades dos grupos de atividades

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

32

semnticas associadas as autorizaes aplicadas a cada funo a ser desempenhada pelos

Authorization as ER
Classes Objects Fields

1-n na task e n-n no cdigo abap

Authoriz.

Values

Transaction

Profiles

Users

Authorization Checks
Quando o usurio efetua o logon no sistema suas autorizaes so carregadas para a user context area (que fica na roll area da instncia) e so verificadas a cada transao ou atividade executada pelo usurio. Antes que uma determinada transao ou operao ocorra, os fields do authorization object so checados contra os fields do usurio para aquele mesmo objeto de autorizao. Esta operao do tipo AND, ou seja, todos os n fields do objeto tem que ser atendidos. Caso a verificao falhe, o usurio recebe uma mensagem de erro e a operao no executada. Caso o usurio possua duas autorizaes contrastantes, vale aquela que libera o acesso, j que

Para simplificar, podemos entender que a verificao de segurana ocorre nos seguintes em passos : Para ganhar acesso a transao Verifica se o usurio est autorizado a acessar a transao atravs da verificao do objeto s_tcode Verifica o objeto associado a transao em questo e se o usurio tem autorizao para este objeto e quais so elas. Ex. O usurio possui o s_tcode para mm01, mas possui o valor 03 para o campo actvt do objeto m_mate_sta Durante o processamento do cdigo abap Verificao das autorizaes verificadas pelo comando abap authority-check Algumas outras dicas isoladas de autorizaes : Durante um call transaction os dois primeiros passos, relacionados a segurana da transao, Se o buffer do usurio for pequeno demais (veja parmetro auth/auth_number_in_userbuffer) algumas autorizaes podem ser perdidas Se for necessrio cancelar a verificao do s_tcode utilize o parmetro auth/no_check_on_tcode Se for necessrio saber quais autorizaes esto carregadas no buffer utilize a transao SU56 e se for necessrio saber qual autorizao est faltando utilize a SU53

Dicas de tabelas: Tabela TACT contm todos as atividades possveis no r/3 e a TACTZ contm o relacionamento das atividades possveis para um objeto

Profile Generator
O profile generator (PFCG) uma ferramenta que simplifica a administrao de segurana atravs de uma viso voltada para o menu de transaes da empresa permitindo que de forma mais interativa se crie e associe profiles para usurio ou grupo de usurios que executam determinada funo. Este

33

grupo lgico de funes comuns que possuem profiles comuns so denominados Activity Groups. Um usurio pode estar associado a um ou mais activity groups. Ao se associar uma transao a um determinado activity group, o profile generator automaticamente identifica os authorization objects necessrios para aquela atividade e os associa a profile que ser gerada. Caso os fields sejam customer-independents, o sistema j prov os valores necessrios para a atividade, caso contrrio os valores precisam ser completados pelo administrador durante o processo de gerao. Ao gerar um activity group o administrador de segurana dever checar os valores propostos pelo sistema para os diversos field e altera-los ou prov-los conforme o caso, antes de salvar o processo O R/3 permite ainda que se crie os activity group com responsabilities, o que permite que uma mesma descrio funcional (activity group) seja associada para diferentes grupos de usurios, provendo assim diferentes nveis de autorizao dentro de uma mesma funcionalidade. Isto simplifica a administrao de segurana. Neste caso os usurios so associados a responsabilitie e no mais ao activity group. Isto significa que caso grupos distintos de usurios que efetuam as mesmas transaes em um sistema R/3 diferindo apenas nas autorizaes para operaes permitidas dentro destas transaes no mais precisam ser administrados a partir de activity groups distintos, mas sim atravs de responsabilities distintas dentro do mesmo activity group. Neste tipo de administrao, as autorizaes para transao so associadas apenas uma vez no activity group para os diversos usurios, o que simplifica caso uma nova transao comece a fazer parte de suas atividades. Ao exibir a lista de autorizaes no profile generator, o sistema divide a exibio em 3 nveis: primeiro nvel contm as object class, por exemplo Standard Finantial Accounting - FI segundo nvel contm os authorization objects, por exemplo Customer: Authorization for No terceiro nvel contm authorizations, por exemplo Customer: Authorization for company codes T..... e abaixo dele o sistema lista todos os fields com seus respectivos valores

Nesta lista possvel dar manuteno nos valores (clicando no lpis) ou ainda obter documentao detalhada de um authorization object s dar um duplo click na sua descrio (segundo nvel). Ao se clicar no item da montanha (authorization object) possvel obter uma lista das transaes daquele activity group que necessitam deste objeto de autorizao. O profile generator possui outra caracterstica. Nele possvel fazer o apontamento para os usurios que iro possuir um determinado perfil. Neste caso devemos executar o programa RHAUTUPD para rever as profiles e task profiles dos usurios. Na prtica o programa varre o cadastro de usurios removendo todas entradas relacionadas ao grupo de atividade que esta sendo trabalhado e depois insere-as novamente. Se for necessrio fazer isto para todos os grupos de atividades devemos utilizar a transao PFUD, que aciona o programa RHAUTUP1. recomendado que este programa esteja agendado para rodar diariamente durante o periodo noturno. Com isto temos a garantia que os apontamentos sempre estaro corretos. Os principais passos para a criao de um perfil, tambm conhecido como activity group, so : Especificar as atividades que sero desenvolvidas a partir dos caminhos de menu Criar as responsabilidades (opcional) Criar a authorization profile Associar os usurios ao activity group Atualizar, utilizando o rhautupd, o mestre de usurios Devemos procurar sempre alterar o nome gerado pelo standard para facilitar o compreendimento e a localizao. A SAP sugere que o nome sempre comee por S_. O profile utiliza as cpias de algumas tabelas standard (USOBT e USOBX) para trabalhar. A USOBT_C contm os objetos que precisam ser verificados e a USOBX_C os valores necessrios aos objetos. Estas tabelas podem ter seus contedos mantidos pela transao SU25. J a transao SU24 pode ser utilizada para ajustar os checks dos objetos. Como ilustrao, a transao SU24 mantm o tipo de check que ser feito, a saber : U no mantido; N no checked; C checkado mas os valores no so mostrados no profile generator e CM o check feito e o profile

34

User Master Record

Atravs da transao SU01 possvel dar manuteno nos usurios. As informaes esto agrupadas por identificao e localizao, dados de logon, defaults, task profiles, profiles e SU3 (ou System Own data) permite que o prprio User profile usurio altere seus dados, tais como Address, Defaults e Parameters, sem violar a segurana de acesso estabelecida pelo administrador. Lembrar sempre que se for associar uma task ou responsibility (profiles geradas por profile generator) a um usurio, o correto faze-lo pela pasta de task profiles. Se a incluso for feita pela pasta de profiles a autorizao vai funcionar mas na prxima reconciliao (execuo do rhautupd) este dado ser perdido pois vai prevalecer apenas as profiles adicionadas na task profiles.

Settings for System Profile Parameters

Diversos parmetros configuram o funcionalidade de segurana no R/3, a saber : Configurar o tamanho mnimo 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 usurios aps logons incorretos, login/fails_to_user_lock com default 12 Fechar a sesso aps 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 parmetros para configurar o sistema de segurana de login do R/3. Para maiores informaes pesquise a nota 66533 e a 68048. Outra boa dica a remoo do sap* na tabela usr02. Com isto, e a alterao do parmetro que impede do sap* logar, voce pode utilizar o sap* com a senha pass. A transao SUIM exibe, atravs da SARP ou SU01->information, a lista de todos os usurios bloqueados no sistema e mais uma dezena de relatrios de usurios, profiles e outros relacionados ao tema.

Security
Os clients 000 e 001 possuem os users SAP* (pwd 06071992) e DDIC (pwd 19920706) com, por default, autorizaes SAP_ALL, devendo o administrador alterar suas senhas na instalao. O client 066 utilizado pela SAP para consultoria remota possui o usurio EARLYWATCH (pwd support) que

O SAP possui um usurio SAP* com password PASS e autorizao SAP_ALL hard-coded em todos os seus sistemas. Isto significa que quando no existe um usurio SAP* na user master table (USR02) do sistema, este usurio pode ser usado para efetuar logon como SAP_ALL. Por razes de segurana portanto interessante que sempre tenhamos um usurio SAP* definido em cada client. A nota 68048 sugere um parmetro (login/no_automatic_user_sapstar) que quando especificado suprime a possibilidade de utilizao deste SAP* hard-coded. Porm sempre que se for criar um novo client necessrio permitir a existncia desta feature hard-coded para que se possa logar no novo

Information System e Authorization Traces

O R/3 permite que se check quais verificaes de segurana esto sendo efetuadas em uma determinada execuo de programa atravs de traces, que so ativados atravs do caminho Tools System trace (veja nota 66056 para detalhes de utilizao) ou Monitor Traces Administration ST01. O log gravado no diretrio \usr\sap\SID\DVEBMGS00\log\trace*.log.

35

Para uma analise localizada de falha de segurana pode-se utilizar a transao SU53, que exibe quais authorizations so requeridas em determinada task. A transao SU56 exibe o buffer de autorizao do usurio. Se uma determinada autorizao no est aparecendo, verifique: Se no houve uma manuteno de profile ou activity group enquanto o usurio estava logado. Neste caso necessrio um novo logon Se as autorizaes foram alteradas atravs de um transporte, preciso emitir um reset dos user buffers para que os novos dados sejam carregados (SU01 Environment Mass Reset all user buffs) changes Se o buffer no est muito pequeno. O parmetro auth/auth_number_in_userbuffer define o nmero de entradas reservada nesta rea para cada usurio, devendo ser aumentado se for o caso Ao se criar um usurio pela SU01 deve-se especificar a sua categoria, se Dialog, BDC (batch input), Background (batch jobs) ou CPIC (para conexo remota). Algumas destas categorias tem caractersticas prprias, como dialog ou background, mas servem tambm como informao documentacional.

Password Rules
Existem uma srie de parmetros para configurar o tratamento que o R/3 vai dar a senha do usurio. Alm da lista abaixo ainda podemos fazer uso da tabela USR40, atravs da SM30, para inserir palavras ou seqncias de caracter que no poderam ser utilizadas na senha. As entradas na USR40 podem tambm fazer uso de wildcards como *. Alm disso temos as seguintes regras : Tamanho mnimo da password (login/min_password_lng) com default 3 Primeiro caracter diferente de ! e ? Os tres primeiros caracteres no podem ser o mesmo nem ser iguais a parte do user name No pode ser sap* ou pass Nmero mximo de erros na senha para fechar a sesso (login/fails_to_session_end) com default 3 Nmero mximo de erros na senha para bloqueio da chave (login/fails_to_user_lock) com default 12 Libera os usurios que esto bloqueados por logon incorreto a meia-noite (login/failed_user_auto_unlock) Nmero de dias para que a senha expire (login/password_expiration_time) com default igual a 0, que significa que nunca expira O R/3 tambm j vem preparado (hard coded) para impedir uma srie de outras senhas, a saber :

Profile Generator Setup

Para ativarmos o profile generator devemos seguir alguns passos, a saber : Gerar o enterprise IMG atravs da SPRO, se ningum tiver feito. Provavelmente o time Ativar o profile generator atravs da incluso do parmetro auth/no_check_in_some_cases = Y Desativar a solicitao a todo instante de chance request pelo profile generator atravs da Criar a classe de desenvolvimento utilizando a transao OY08 Criar as cpias das tabelas standard (USOBX e USOBT) que o profile generator necessita para gerar os grupos de atividades, utilizando a transao SU25 Alterar os check indicators e os valores dos campos dos objetos de autorizaes 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 o cadastro de usurios no. Com isto temos um inconveniente que quando transportamos o grupo de

36

atividades perdemos o link com os usurios que possuem este grupo no ambiente de destino. Por outro lado, podemos levar todo o cadastro de usurios de um mandante para o outro. Isto pode resolver problemas pontuais mas no resolve o problema da manuteno das profiles que esto na produo e nem do ciclo normal de trabalho com os grupos de atividades. Para transportamos um grupo de atividade, lembre-se ele foi desativado pela transao OOCR, devemos clicar no icone do caminho na transao PFCG para transportarmos um grupo de atividade especifico. Para transportamos um conjunto de grupos de atividades devemos utilizar o programa RHMOVE30 que possui diversas formas de seleo. Aps importarmos a change que foi gerada no ambiente de destino devemos executar a transao SUPC para regerarmos a profile. Neste caso, quando geramos um grupo de atividade que veio do ambiente de desenvolvimento, precisamos atualizar a tabela T77TR (utilizando a SM31) para que o transporte fique configurado para no perder a associao com os usurios no ambiente de destino nos prximos transportes deste grupo de atividades.

SAPRouter
O SAPRouter um componente de software que vem com o R/3 ( no unix um script que pode ser adicionado no startsap e no NT um servio que deve estar ativo) para viabilizar a ligao de duas redes com a garantia de segurana e proteo de acesso em cada uma delas pelo proprio parceiro. Com o SAPRouter voce pode : Controlar e logar as conexes com o sistema R/3 Permitir que outros saprouters tenha acesso a uma rede especfica Proteger o sistema contra conexes e envio de dados de usurios no autorizados Encripitar senhas e outros dados por parceiros certificados pela SAP Controlar o acesso ao servio de OSS da sap Para utilizar o SAPRouter precisamos criar o diretrio saprouter debaixo da arvore \usr\sap; obter a verso mais nova disponvel no OSS e criar a tabela de rotas permitidas no arquivo \usr\sap\saprouter\saprouttab. Esta tabela que contm a definio de quem poder ou no passar de um lado para o outro. Ela um arquivo texto com cinco campos, a saber : Permit/Deny/Secure, endereo de origem, endereo de destino, servio e password. Os endereos podem tanto ser hostnames com ip e neste ultimo caso podemos utilizar tambm os wildcards para selecionarmos uma rede inteira (Ex. 123.45.*). J o servio e a password so opcionais, sendo que o servio assume o defalt de 3299 que a porta padro utilizada normalmente para saprouter. A grande dica na construo da routtab a definio do que proibido no inicio do arquivo e do que permitido no final. Isto necessrio por que a leitura e deciso feita do primeiro para o ultimo. Para especificarmos uma rota para o saprouter devemos utilizar o mesmo padro utilizado no SAPGUI. A nica novidade a chave /W/ para conter uma eventual password a ser passada a um saprouter. 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>. O saprouter possui uma srie de variaes de parmetros. Elas podem ser obtidas simplismente acionando o saprouter na linha de comando sem parmetros. Algumas delas so importantes como R para dizem onde esta a routtab, -r para startar o servio, -s para parar o servio, -r V3 para selecionar o nvel mais alto de trace, -t para ativar o trace, -T para dizer onde vai ser gravado o arquivo 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 os dados que iro transitar na rede e para autenticar as senhas de usurios. Normalmente o R/3 no faz criptografia de dados e a senha transita pela rede como caracter. O SNC uma camada na arquitetura R/3 que estabelece um padro de interface para os softwares de segurana e autenticao de usurio disponveis no mercado. Atualmente os softwares certificados pela SAP so o Kerberos 5 do MIT e o Secude 5. Para maiores detalhes veja a nota

37

66687. O padro SNC prove trs nveis de segurana, a saber : A autenticao da comunicao entre os parceiros sem a proteo do dados que ser trocado; Integridade que garante a autenticao e mais uma assinatura digital da informao que est trafegando para garantir sua autenticidade; e Confidencialidade que garante a autenticao a integridade e a confidencialidade que o dado no pode ser interpretado por outro que no sejam os parceiros da comunicao. Para ativarmos o SNC temos que definir qual ser o padro de nome dos usurios. Podemos escolher entre X.500 (que distingue o nome pela formao de diversos elementos), nome@dominio (que usa uma concatenao simples do nome do usurio e de seu domnio) e o padro de nome externo do R/3. Alm de definirmos o padro de nomes temos que incluir o parmetro snc/enable = 1 na default profile para ativar efetivamente o SNC. Com isto a SU01 passa a possuir mais uma pasta que contm o nome SNC do usurio. Podemos ainda alimentar a tabela USRACL, que contm o depara, diretamente com o nome interno e o nome externo dos usurios. Para os usurios RFC e CPIC podemos definir apenas um usurio interno para vrios usurios externos atravs da tabela USRACLEXT. Podemos tambm ativar nveis de insegurana para alguns casos. Por exemplo, aceitar sesses no seguras atravs do parmetro snc/accept_insecure_gui =1 ou snc/accept_insecure_cpic = 1. Alm da SU01, outras transaes passam a possuir maiores detalhes sobre o SNC, a saber : SM59 que controla as chaves RFC; a SM54 que controla as chaves CPIC e a SNC0 que controla a lista de acesso entre sistemas R/3. A utilizao do SNC pressupe a instalao de uma dll (secure.dll) junto com o SAPGUI alm do cliente do software de segurana que ser utilizado. Para o saplpd temos que incluir na cliente uma entrada 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 recomendaes para implementar o SNC. A primeira nunca misturar applications que utilizam SNC com outros que no utilizam. A seguinte ter certeza que o produto de segurana est apto a trabalhar com os padres de nomes estabelecidos pelo R/3; E por fim garantir as definies do nvel de proteo desejado, dos parceiros e protocolos que sero implementados, quais conexes sero protegidas e as respectivas portas a serem bloqueadas pelo

38

Software Logistics
R/3 System, Servers and Instances
Uma instncia R/3 um grupo de servios que so inicializados e parados simultaneamente por um dispatcher, possuindo em comum uma profile de instncia. O nome de uma instncia composto pelos nomes que identificam os servios (Dialog Update (Verburren em alemo) Enqueue Background Message Gateway) por ela executados. Uma central instance contm tipicamente todos os servios R/3 instalados, da o seu nome ser DVEBMGSnn, j uma dialog instance possui o nome Dnn, onde nn o system number utilizado para compor o nmero das portas que efetuaro as chamadas ao dispatcher (32nn) e ao message server (36nn) na camada TCP/IP. Um server pode conter uma ou mais instncias R/3 configuradas. Um PC com o frontend SAPGUI instalado tambm considerado um server da camada presentation na arquitetura R/3. O database server um hardware que possui o RDBMS relacional instalado. comum em R/3 instalarmos o database server no mesmo host que contm a central instance. O conjunto de todos estes servidores com suas respectivas instncias R/3 compem 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 so 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 so as informaes pertencentes a todo o sistema, como algumas configuraes ou o repositrio de objetos O dicionrio ABAP um dicionrio de dados que faz parte do repositrio ABAP de um sistema R/3. Seus dados so client independents. Os programas ABAP armazenados no dicionrio so compilados uma vez no primeiro acesso (early binding) e ficam armazenados em um outro repositrio de executveis (tabelas D010*). Cada alterao em um programa fora a sua posterior. Este procedimento denominado late binding possvel atravs de um mecanismo de comparao de timestamp. Este mecanismo de early binding e late binding garante que a integridade das informaes contidas no dicionrio ABAP no afete a performance do sistema, uma vez que os executveis de telas e programas so mantidos atualizados automaticamente em uma rea separada dos respectivos fontes.

R/3 Clients
Um client em R/3 uma unidade independente em termos organizacionais, tcnicos e comerciais. Um client possui seus prprios usurios e seus prprios dados nas tabelas do R/3. Isto permite que um nico sistema R/3 administre vrios clients diferentes, cada um com seus prprios dados. Como a base de dados (consequentemente as tabelas) em um sistema R/3 os dados dos diferentes clients ficam armazenados no mesmo local e so diferenciados pelo kernel do R/3. Na prtica o R/3 implementa esta separao atravs de um campo MANDT (de mandante, ou client em alemo) que participa da chave primria das tabelas client dependents do R/3. Em qualquer chamada a estas tabelas o sistema incorpora na clausula WHERE do SQL o campo MANDT = nnn. A nica excesso a tabela T000 que defini quais so os clientes existentes na instncia e uma tabela com

Este campo que identifica um client composto de que sempre que efetuamos um logon informemos o nmero do client. Este campo tela de login inicial do R/3, juntamente com a chave e a password do usurio. Como os dados de clients diferentes funcionam no R/3 como bases de dados diferentes (separao por kernel), as empresas quando desejam implementar uma administrao coorporativa de suas subsidirias, o controle centralizado possvel atravs de uma outra facilidade que o campo configurvel

39

denominado company code. Este campo define a menor unidade administrativa com que os relatrios externos podem varrer para uma viso centralizada. O conceito de authorities do R/3 sobre este campo company code permite ainda que uma companhia matriz acesse as suas filiais com finalidades de consultas ou auditoria impedindo que as diversas subordinadas tenham acesso aos dados umas da outras.

Standard Client Roles

recomendado que um ambiente R/3 de uma empresa tenha no mnimo os seguintes clients: Client CUST, como o ambiente central onde o desenvolvimento e as customizaes so efetuadas pelos times funcionais e de abap. Neste client podemos fazer alteraes no ambiente e gerar change request Client QTST, utilizado para o teste de novas customizaes Client PROD, que a produo da empresa Em um ambiente ideal, os seguintes clients adicionais so recomendados: Client SAND, que um sandbox onde novas customizaes so experimentadas antes de efetivamente efetuadas no ambiente CUST. Neste client podemos fazer alteraes mas no podemos gerar change request Client TEST, para teste de customizaes 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 compreendendo normalmente um desenvolvimento, uma qualidade e uma produo que compartilham change requests e rotas de transporte com o propsito de manter um sistema de desenvolvimento e customizao consistente. Por questes de segurana, aconselhado proteger o sistema utilizando o conceito de clients, implementando a segurana atravs do conceito de autorizaes garantindo a separao dos dados entre clients. aconselhvel ainda separar fisicamente os ambientes de implementao do desenvolvimento, qualidade e produo. Alm das questes bvias de segurana e performance do ambiente produtivo, tal implementao protege o sistema evitando que configuraes client independents do ambiente de desenvolvimento sejam implementadas na

Uma implementao em dois ambientes tambm no aconselhvel porque todos os objetos transportados para o ambiente de consolidao ficam imediatamente valendo no ambiente de produo. A implementao mais recomendada pela SAP um landscape de trs ambientes que implementam clients e rotas prprias de transporte, consistindo dos 3 clients bsicos e os 3 adicionais: Um host composto de trs clients (SAND, TEST, CUST) onde fica o ambiente de desenvolvimento Um host de quality assurance (com dois clients QTST e TRNG) onde os novos desenvolvimentos so testados antes de serem migrados para o ambiente produtivo Um host para o ambiente de produo com o client PROD Os sistemas R/3 que compem um mesmo landscape devem possuir system IDs diferentes para a correta identificao das rotas de transporte

Change Requests and Transports

O sistema R/3 integra mais de 800 processos de negcio que precisam ser customizados e configurados de acordo com as necessidades de cada empresa para atender e se adequar ao seu ramo de negcio. Atravs de customizaes e desenvolvimentos especficos o sistema R/3 adaptado ao processo de negcio da empresa e estas alteraes precisam ser distribudas entre todos os clients que compem o landscape da empresa, garantindo assim a consistncia do sistema.

40

Transport Management
Transport Process
O TMS a ferramenta existente no R/3 onde esto centralizados todos os recursos para efetuar e gerenciar os transportes no ambiente. At o release 3.1H os transportes eram efetuados atravs de ferramentas no sistema operacional e baseava-se nas configuraes das tabelas TSYST, TWSYS, TASYS e DEVL principalmente. O primeiro passo no processo de transporte o release dos change requests que so exportados para files do diretrio comum de transporte (\\hostgroup\sapmnt\trans). Para cada change liberado, arquivos so gerados nos subdiretrios data (dados exportados) e cofiles (control files). Este diretrio de transporte tambm possui um subdiretrio buffer que contm um import buffer file para cada sistema que compartilha aquele transport group. Cada change liberado acrescenta uma entrada neste file de forma que ele conter informaes sobre os transportes que esto disponveis para import e a seqncia de importao. Esta informao acessada no TMS atravs da facilidade das import queues A rota de consolidao nas quais os transportes so liberados normalmente especifica um sistema de quality assurance para validao das changes. Quando se efetua o import do transporte para este sistema QAS, o sistema coloca as entradas no import buffer do sistema de delivery, normalmente o PRD, ou algum outro especificado no TMS. O processo de validao no sistema QAS poder detectar erros que sero corrigidos no DEV e novamente transportados para consolidao. A fila de import do sistema PRD poder ento conter mais um import que dever ser efetuado. Um ciclo de alterao poder conter um ou mais change requests, dependendo da necessidade de correo aps os testes no QAS. Quando finalmente o processo estiver pronto para import no delivery (PRD), o TMS permite que toda a fila de import seja efetuada carregando o sistema de produo com a verso final do objeto. Para o correto funcionamento deste mecanismo imprescindvel garantir que os transports sejam importados na correta seqncia.

Import Queues
A ferramenta mais importante para o mecanismo de import do TMS so as import queues que refletem a situao dos import buffers de um determinado sistema. Ela lista os change requests disponveis para import bem como a ordem com que foram liberados. Os dados exibidos no TMS so lidos no momento em que a transao chamada. A opo de refresh permite atualizar as informaes 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 de desenvolvimento do projeto onde o numero de change requests muito grande. Durante a manuteno do sistema normalmente no utilizado pois o nmero de changes provavelmente ser bem menor. Atravs da administrao da fila de imports possvel excluir change requests, efetuar forwards para outros sistemas, estabelecer dead lines e end marks, etc. A administrao do TMS permite muita liberdade no tratamento das filas, porm recomendvel que estas manipulaes sejam bastante conscientes para garantir a integridade e consistncia dos transportes. A SAP um pouco mais forte que a vida real, ela recomenda que nenhuma change seja deletada ou manipulada na fila para evitar qualquer tipo de consistncia. Para estabelecer end marks nas filas de import necessrio fechar (close) nas filas. Este processo eqivale a estabelecer stopmarks nos files do sistema operacional (tp setstopmark <SID>). A diferena bsica que enquanto no sistema operacional possvel acrescentar uma stopmark apenas no final da fila, atravs do TMS possvel colocar o end mark onde for mais conveniente. Este processo muito til quando desejado disparar um import em bloco porm at um determinado ponto apenas. O import all (caminho) efetua o import at encontrar a marca postada na fila. Operacionalmente recomendvel que sempre se feche a fila (end mark) antes de iniciar um import, evitando que requests liberados durante o processo tambm sejam transportados inadvertidamente.

41

Para evitar inconsistncias entre change requests, somente efetue imports de changes isolados quando, com completa certeza, conhecer o seu contedo e sua dos demais requests. Estes imports so denominados Preliminary imports. Como garantia, o TMS mantm os preliminary imports na fila para que sejam retransportados quando se efetuar o import padro (all). Em condies especiais possvel especificar parmetros diferentes quando do import. So as comando tp no sistema operacional. Este processo chamado expert mode. Existem uma srie de opes nos expert modes e elas sero detalhadas mas adiante.

Transporting Between Transport Groups

Transporte so gravados nas import queues de um determinado transport group que compartilha o mesmo diretrio de transporte. A opo In foreign groups (Extras -> Other requests -> In foreign groups) permite que se efetue transporte entre sistemas que possuem diferentes diretrios de transporte. Esta opo til quando o compartilhamento NFS dos sistemas no permitido por alguma razo tcnica (conexo ruim, segurana, compatibilidade, etc.). Neste caso o TMS cuida de sincronizar as informaes entre os buffers do grupo de origem e do o grupo de destino.

Transport Monitoring
possvel monitorar o processo de transporte atravs de uma srie de ferramentas do Import Monitor do TMS. O sistema permite ainda que se verifique a consistncia dos arquivos no sistema operacional (Consistency check) e o return code produzido por cada transporte atravs da visualizao da ALOG. O TMS tem ainda ferramentas para testar as funcionalidades do tp program e ainda verificar a configurao do diretrio de transporte (System check) alm do funcionamento das conexes RFC com os sistemas que compem o landscape. Atravs do Alert Monitor do CCMS possvel integrar algumas funes de monitorao com o TMS permitindo a gerncia centralizada do sistema R/3.

Transport Process
O processo de transporte pode ser descrito nos seguintes passos: O lder do projeto libera o change request aps verificar o trmino das tasks com os integrantes do grupo de trabalho O lder 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 consolidao e garante a execuo correta do processo com return codes aceitaveis. O time funcional garante os testes exaustivos no ambiente de consolidao. Qualquer problema detectado dever ser informado ao lder do projeto para que se inicie a correo e repita o export de uma nova correo para o sistema de consolidao O administrador do sistema efetua o import para o ambiente de delivery e demais sistemas configurados do conjunto consistente de change requests no landscape e garante a execuo correta do processo com a devida verificao dos return codes. Durante o processo de testes de uma funcionalidade pode ser necessrio congelar o trabalho no ambiente de desenvolvimento para garantir a estabilidade dos testes. Isto facilita a correo de possveis problemas encontrados nos objetos, que seria mais difcil de ser corrigido se o processo de desenvolvimento tivesse continuado no objeto durante os testes. Uma estratgia peridica para a importao dos transportes dever ser implementada e negociada com as equipes de desenvolvimento. Import all devero ocorrer mensalmente, semanalmente ou diariamente. Imports mais freqentes no so recomendados no ambiente R/3. O processo de import deve ser feito durante a baixa atividade do sistema e logo aps um backup da base. A SAP recomenda que o transporte de um projeto seja efetuado apenas quando todos os seus componentes estiverem totalmente desenvolvidos evitando a estratgia de enviar objetos individualmente a medida

42

Advanced Transport Management

Transport Directory
Os change requests so gerados obedecendo a nomenclatura <source SID>K9nnnnn onde nnnnn um seqencial de 5 dgitos controlado pelo sistema source (tambm conhecido como sistema integrador ou sistema de desenvolvimento e configurao). O file system do diretrio de transporte fica montado na rea compartilhada /usr/sap/trans de uma das mquinas (normalmente aquela de onde os transportes se originam) e atravs de NFS, o file system compartilhado com os demais sistemas que compartilham o mesmo transport group. No ambiente do NT o compartilhamento feito atravs do sapmnt que contm, entre outros, o diretrio trans contm os seguintes subdiretrios, entre outros: actlog, onde so gravados cada action em um request ou task. Contm files com nomes <source SID>Z<6 digits> sapnames, com arquivos com o nome do usurio 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 contm os dados que foram exportados no transporte. Eventualmente neste diretrio podemos ter arquivos no formato D9<5 digits>.<source SID> que tambm contm dados a serem importados. cofiles, com command files do tipo K9<5digits>.<source SID> contendo por exemplo os import steps que sero executados log, com todas as logs de transportes, como por exemplo ULOGs, ALOGs, SLOGs e as demais logs que descrevem as operaes executadas nos steps individuais ou coletivos bin, com os arquivos de configurao do funcionamento do mecanismo de transportes (TPPARAM e DOMAIN.CFG) tmp, com os arquivos de log que esto sendo gerados durante o processo. Aps o trmino de um transporte os arquivos so movimentados para o diretrio LOG.

The tp Program
O transport control program uma ferramenta executada a nvel de sistema operacional que controla todas as operaes de transporte no sistema R/3 usando programas especiais (por exemplo em C), comandos de sistema operacional e programas ABAP no R/3. O TP opera as operaes de export e import separadamente, extraindo/atualizando as informaes de controle na base de dados do R/3 e levando para files (buffer, log e cofiles) no diretrio de transporte e posteriormente, atravs de comando explcito, importa os dados no sistema destino. Ele no faz a manipulao dos dados que sero transportados (o responsvel por isso o R3trans que ser visto a seguir). Apesar de ser uma ferramenta no sistema operacional (diretrio de exes), o tp deve ser utilizado atravs da interface do TMS que efetua as chamadas apropriadas para cada tarefa. Sua utilizao 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 especfico tp go <SID>, checa o database de um sistema destino tp connect <SID>, checa a conexo tp showinfo <request>, exibe informaes 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 parametrizao atual de um sistema tp status <SID>, exibe o status de serializao de um sistema O comando tp import all <SID> client=nnn executa o import de toda a fila de transporte do sistema <SID> no client nnn. Este o comando normalmente emitido pelo TMS.

43

O comando tp import <request> <SID> client=nnn u0 executa o import de um request especfico e o mantm na fila, eqivalendo ao preliminary import do TMS. Quando se suprime a opo u0 o request retirado da fila de import. preciso tomar cuidado com imports individuais para garantir a manuteno da seqncia correta com que os mesmo foram exportados.

O import mode incondicional (com especificao da opo ) 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 especficos do sistema u6, sobrescreve objetos em modo unconfirmed u8, ignora restries estabelecidas na tabela de classificaes u9, ignora o fato do sistema estar lockado para este tipo de transporte O buffer de um determinado <SID> manipulado pelos comandos tp especficos, como por exemplo addtobuffer, showbuffer, delfrombuffer, cleanbuffer, setstopmark e delstopmark. Estes comandos manipulam as linhas do arquivo especfico de cada sistema existente no subdiretrio 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 por exemplo o R3up. Efetivamente o R3trans que vai ler os dados para construir o arquivo K9xxxxx e durante o processo de import vai ler os dados neste arquivo para fazer a atualizao dos dados da request em tabelas temporrias no banco de dados do sistema destino. O uso direto do programa R3trans no suportado e somente utilizado em casos muito especiais. A SAP no suporta ainda o uso 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 so executados no ambiente R/3. O programa RDDIMPDP um programa schedulado no ambiente para ser disparado pelo evento SAP_TRIGGER_RDDIMPDP. Este evento disparado no momento correto devido ao programa tp atravs de chamada ao sapevt. Este programa tem que estar schedulado corretamente (baseado no evento) pelo user DDIC no client 000 e em cada client que receber transportes para que o import funcione corretamente ( possvel verificar isso utilizando o comando tp checimpdp SID). A execuo do programa RDDNEWPP efetua este schedule no sistema, embora o sistema normalmente schedula este job automaticamente aps um client copy. A verificao do schedule pode ser efetuada pela SM37. O programa RDDIMPDP se baseia em informaes passadas pelo programa tp para ativar programas RDD* que efetuam tarefas especficas requisitadas pelo tp. As principais tarefas, a saber, so : mass activation (rddmasgl), convertion and generation (rddgendb) e versioning management (rddversl).

The Import Process

O processo de import composto de uma srie de steps que executam tarefas distintas e, dependendo do tipo do transporte, so ativados ou no. A organizao da fila de import no buffer file uma espcie de tabela onde para cada entrada referente aos requests, colocado um flag 0 ou 1 na posio referente a cada step. O programa tp no l esta fila individualmente, mas sim coletivamente. Desta forma o processo de import ocorre de forma seqencial no pelos requests, mas sim 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 fila de transporte mais de uma referncia a um determinado objeto (por exemplo a segunda corrigindo um erro detectado em uma primeira consolidao) o step de ativao (posterior ao de importao) ocorra

44

somente quando a verso correta esteja importada no sistema, evitando desta forma que a verso com erro seja ativada temporariamente como ocorreria se o processo fosse seqencial por request. Para garantir a consistncia do tratamento da fila de import, o programa tp coloca automaticamente um setstopmark na fila no incio do processo e a retira no final. Cada operao efetuada durante o processo logada pelo tp com o respectivo return code nos arquivos de log do sistema de transporte. Ocorrendo erros no processo o programa tp interrompe e aps a correo pelo administrador, um restart faz com que o tp encontre o ponto de parada e recomece o processo a partir daquele ponto. Qualquer return code maior que 8 interrompe o programa tp. Este valor entretanto pode ser configurado no arquivo TPPARAM (atravs do parmetro stoponerror) Os passos durante o import so (os passos com * so genricos 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 no foi implementada e ser utilizada para a importao 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 subdiretrio 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 subdiretrio log. A comunicao entre o programa tp e os jobs background no sistema se d atravs da tabela TRBAT que contm dados temporrios. O tp grava nesta tabela os steps que devero ser executados durante o import e ento dispara o evento que ativa o RDDIMPDP. Este programa por sua vez l a tabela e atravs das informaes recolhidas dispara programas RDD* que efetuam tarefas especficas requisitadas pelo tp. Cada um dos jobs RDDs disparados pelo RDDIMPDP registrado na tabela TRJOB atravs de uma entrada onde so gravados seus return codes que desta forma podem ser acompanhados pelo programa tp. As logs geradas pelos programas RDD* so gravadas no subdiretrio tmp e posteriormente transferidas para o log pelo programa tp. Qualquer problema detectado pelo tp durante a monitorao das tabelas TRBAT e TRJOB faz com que o tp reative o RDDIMPDP atravs da emisso de novo evento pelo sapevt. O RDDIMPDP analisa estas tabelas e verifica se o processo anterior ainda est ativo ou se necessrio, processo no step cancelado. Por este motivo que pelo menos dois background process precisam estar disponveis para o sistema de transporte.

45

Transport Monitoring
Todas as logs do processo de transporte so gravadas no subdiretrio de log. So logs criadas pelo tp program (ULOG, SLOGs e ALOG) e pelas demais ferramentas de transporte. A ULOG contm todos os comandos tp sem erros de sintaxe. Cada linha representa um comando. Existe um arquivo SLOG<YY><WW>.<SID> para cada sistema R/3 do landscape e usado para monitorar as atividades de transporte de um sistema especfico. Contm uma viso geral dos imports efetuados indicando os respectivos return codes e consequentemente o sucesso de cada import. O ALOG<YY><WW> contm todos os return codes de cada um dos steps executados nos processos de import efetuados no seu transport group. Alm destes arquivos de log, o diretrio de logs possui uma log por change request. Estes arquivos 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 so consolidados pelo programa tp da seguinte forma: 0 a 16, indica os valores mximos de todos os return codes das ferramentas 17 a 99, que um valor calculado a partir daqueles retornados pelas ferramentas de transporte e so warnings indicando problemas detectados pelo tp, como por exemplo a no permisso de write no diretrio buffer 100 a 149, so warnings indicando que alguma coisa vai mal e nem todas as tarefas puderam ser completadas 150 a 199, so erros (raros de acontecer) indicando uma operao ilegal solicitada pelo operador 200 ou mais, indica erros no tp Para obter uma descrio 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 de transporte podem ser visualizadas atravs do Alert Monitor sob a forma de uma estrutura em rvore que pode sofrer drill down. O diretrio de transporte deve ser limpo de tempos em tempos para eliminar transportes antigos e tp check all varre os diretrios de transporte e os arquivos referentes a transportes j executados so 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 no sero mais necessrios e se tornaram obsoletos baseados em timestamps definidos pelos datalifetime, olddatalifetime, filelifetime e loglifetime do TPPARAM. Antes de efetuar esta operao recomendado que se efetue uma cpia backup por segurana.

46

R/3 Upgrades and OCS Patches

R/3 Evolution and Release Strategy
Um sistema R/3 tpico, uma vez instalado, passa por evolues sejam devido a customizaes ou novos desenvolvimentos, como tambm pela aplicao de patches do OCS (Online Correcton Service) ou ainda por upgrade de novos releases. Novos releases no R/3 podem ser de dois tipos: Functional Releases, que trazem novas funcionalidades e so enviados para os clientes apenas sob demanda (3.1G e 4.0A, por exemplo) Correction Releases, trazem apenas correes e so enviadas automaticamente para todos os clientes. Estes so os releases recomendados para serem instalados em produo, j que possuem suporte total do OCS (3.1H ou 4.0B, por exemplo)

R/3 Upgrade
Em um tpico landscape de 3 sistemas, cada ambiente (partindo do desenvolvimento) passa por uma seqncia de transportes standard. So tarefas tais como customizaes, patches, e ajustes no sistema. Estas alteraes so executadas no ambiente de desenvolvimento e transportadas para os demais ambientes. Uma das tarefas mais importantes durante a preparao para o upgrade rodar o script PREPARE (integrante da ferramenta retrofit que integra a localizao que existia na verso 3.0 com o correspondente standard que vem na verso 4.0) e que responsvel por fazer uma srie de checks, a saber : Quais so as verses do banco de dados, do sistema operacional, e do R/3 Quais abaps preciso ser realterados Existe espao suficiente no banco de dados Existe alguma reparao em andamento Quais so as lnguas suportadas Qual o nvel de hot package e se todos esto confirmados usurio tem as devidas permisses no sistema operacional Aps todo este processo o prepare gera um arquivo chamado \usr\sap\put\log\checks.log) no sistema com as aes necessrias para viabilizar o upgrade. A execuo deste script no faz parte do upgrade em si que feito utilizando o programa R3up que tem funcionamento semelhante ao

Durante o processo de upgrade, so efetuadas alteraes de ajuste usando as transaes SPDD e SPAU. O processo de upgrade passa por passos que so efetuados com o sistema ativo ainda no release antigo, a retirada do sistema para que o dicionrio seja atualizado e posteriormente mais tarefas 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 a execuo 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 transferncia para o repositrio do R/3 dos novos objetos enviados em um CD. Este processo passa pela comparao dos objetos para identificar possveis modifications efetuadas pelo usurio nos objetos SAP standard. Todas as modificaes que o cliente desejar manter e cujos objetos SAP no novo release tambm foram alterados, precisam ser casados com os objetos SAP. Este processo executado atravs das transaes SPDD e SPAU e conhecido como Modification Adjustment. Existem diversos tipos de modification adjustment que so executados antes (atravs da SPDD) e depois (atravs da SPAU) da fase do Data Dictionary Activation. Durante esta fase de activation o sistema desativado, que pode durar vrias horas. Aps esta fase o sistema reativado j no novo release.

47

Repository Switch
O corao de um processo de upgrade o Repository switch. Inicialmente um repositrio inteiro na nova verso colocado no sistema e permanece inativo. Este processo requer uma rea adicional em disco que somente ser liberada quando o novo repositrio for ativado e o antigo deletado. Para preservar as modifications introduzidas pelo usurio, durante o processo de switch do repositrio as alteraes introduzidas pelo usurio so transferidas para o novo repositrio atravs da modificao dos correspondentes objetos SAP do novo release. A fase de modification adjustment somente ser necessrio quando o objeto alterado pelo cliente tambm foi modificado pela SAP (seno ele ser movido integralmente) e quando questionado, o cliente decide continuar com suas alteraes por achar que o novo release no incorpora devidamente suas necessidades. Caso o cliente aceite o novo objeto, suas antigas alteraes sero descartadas. No processo de preparao do repository switch acontecem as seguintes operaes: Transfere para o novo repositrio modifications introduzidas pelo cliente cujos objetos SAP no sofreram mudana no novo release Salva no version database todas as modifications que foram efetuadas em objetos que sofreram mudana no novo release. Isto permitir efetuar os ajustes posteriormente Copia os objetos que foram gerados atravs do processo de customizing para o novo Transfere para o novo repositrio todas as documentaes, verses inativas de objetos e desenvolvimentos executados pelo cliente, alm dos objetos locais

Uma vez que as operaes acima foram efetuadas, o repository switch poder ser efetuado. Caso no existam objetos que necessitam de adjustment, o switch uma simples questo de reativar o novo repositrio. simples e rpido, sendo portanto sempre desejvel que os objetos SAP permaneam o mais standard possvel.

Switch log during repository upgrade

Durante o processo de upgrade podemos escolher trs estratgias diferentes para o uso da log de alterao. Independente de cada uma destas estratgias evidente que devemos ter backup full offline de cada ponto do processo para que em caso de pane ou necessidade de retorno a situao anterior tenhamos backup para retornar a situao anterior. As principais fases do upgrade so : Inicializao do processo Importe do repositrio Anlise e copia dos novos objetos Switch, ativao do novo dicionrio e ajuste dos objetos impactados Importe dos dados de controle Importe da lingua portuguesa Fase final e backup aps todo o processo As estratgias disponveis para o upgrade so : A_OFF: neste caso durante todo o processo no 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 a possibilidade de fazer um log-foward. A grande vantagem desta opo a no necessidade de rea para o archive. A grande desvantagem um maior tempo de downtime 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 fase de ativao do novo dicionrio. O consumo de disco menor que na opo A_ON mais ainda considervel. O downtime tambm pequeno mas seguido de um backup offline.

48

Ou seja, ela possui um pouca do lado bom das outras duas e por isto que esta opo a recomendada pela SAP e j o default.

Modification Adjustment
O processo de modification adjustment consiste na transferncia para os novos objetos SAP das modifications introduzidas pelo usurio no release anterior. SPDD utilizada para efetuar esta transferncia em certos objetos do ABAP, tais como domains, data elements, table structures, transparent tables, pooled tables, cluster tables e table technical settings. A no execuo desta tarefa causaria a perda de dados Aps a ativao do novo dicionrio, a transao SPAU utilizada para ajustar alguns objetos que se no ajustados no causariam perda de dados, apenas perda de funcionalidade. Estes objetos seriam objetos de lock, matchcodes e views, alm de objetos do repositrio, tais como ABAP programs, function modules, menus, screens ou module pools Ao trmino da execuo destas duas tasks (SPDD e SPAU), todas as modifications estaro incorporadas no novo release. No release 4.0 o processo de pre-upgrade PREPARE (script mencionado anteriormente e integranda retrofit tool) para o upgrade efetua um check geral do sistema e lista todos os objetos que sofreram modifications e consequentemente necessitaro de passar pelas SPDD e SPAU, podendo desta forma haver um melhor planejamento do esforo a ser gasto no processo. O processo de modification adjustment executa um comparao entre as duas verses do objeto. Para cada objeto, as transaes SPDD e SPAU guiam o usurio atravs dos processos de ajuste, oferecendo ainda a opo de aceitar a nova verso ou executar os ajustes necessrios. Estes ajustes, quando efetuados, sero 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 mais simples pela aplicao destes transports. Este procedimento de transporte simples e poupa esforos de efetuar os adjustments em cada somente possvel apenas se todos os sistemas do ambiente estiverem nos no momento dos upgrades. Um landscape bem planejado e bem gerenciado torna este processo vivel e diminui sensivelmente os esforos no upgrade. Em relao as responsabilidades do processo de upgrade, temos que ter em mente que os administradores do sistema so responsveis pelo upgrade mas os times funcionais e de abap so responsveis pelos ajustes e testes das funcionalidades que sero afetadas pelo upgrade.

Avoiding Modifications in R/3 Systems

Para simplificar os processos de upgrade (minimizando ou at mesmo eliminando a necessidade de efetuar modification adjustments), a SAP recomenda que se evite modifications tanto quanto possvel. Alm de demandarem mais esforos durante upgrades, estas alteraes no standard core do R/3 podem introduzir erros graves no ambiente R/3. Dependendo do nvel destas modificaes e seus reflexos no negcio da empresa, um processo de upgrade poder ser difcil, demorado ou at mesmo impossvel de ser implementado em verses mais recentes do R/3. Em substituio s modifications, a SAP disponibiliza o conceito de enhancements, atravs da user exits e appended structures que tornam o processo de upgrade totalmente transparente para a instalao O conceito de user exits consiste na introduo em determinados pontos mais susceptveis a modifications dos objetos SAP de chamadas a rotinas externas que podem ser desenvolvidas pelo cliente em sua instalao. Novos releases traro estas chamadas nos mesmos pontos no necessitando o cliente de efetuar nenhuma alterao no novo objeto. Os objetos que possuem exit Programas exits, que permitem includes no cdigo atravs de chamadas externas

49

Menu exits, podendo o cliente introduzir novas opes no menu Screen exits, que so telas adicionais Field exits, que so programas ou function modules conectados a um campo de tela para executar funes por exemplo de consistncia personalizada de preenchimento. Ao contrrio dos demais tipos de exits, field exits no precisam ser criadas para um determinado campo, podendo o cliente decidir pela sua colocao em qualquer campo.

As append structures permite que se acrescente campos em tabelas SAP sem a necessidade de alterao dos objetos standard do sistema. Os campos includos ocupam fisicamente uma outra rea e apenas sero incorporados a nova verso do objeto no novo release. Estas estruturas devero possuir nomes no customer range (Z) para evitar que sejam sobrescritas no momento do upgrade. A incluso destas estruturas entretando no so permitidas a pool tables, cluster tables ou tables que possuam campos LONG RAW.

Online Correction Service (OCS)

O OCS oferece patches para correo de um sistema R/3 atravs da disponibilizao de Hot Packages, LCPs, SPAM updates e Conflit Resolution Transport (CRTs). Estes patches reduzem a necessidade de correes manuais no sistema atravs da aplicao de notas que, diferentemente destas correes, no sero reconhecidas por um processo de upgrade como modifications. portanto extremamente aconselhvel que um sistema R/3 esteja up to date no momento de um upgrade para minimizar a necessidade de anlise de modifications que no passam de notas aplicadas. Os tipos de patches na verso 4.0 so : Hot Packages so grupos de vrios patches e devem ser aplicados na ordem em que so disponibilizados pela SAP. Tecnicamente durante a sua aplicao requerem modification adjustments atravs da transao SPAU. LCPs ou Legal Change Patches, so os Hot Packages para o ambiente HR SPAM update uma atualizao para a transao SPAM (utilizada durante a aplicao dos Hot Packages) CRTs ou Conflit Resolution Transports suprem objetos adaptados para resolver conflitos entre o R/3 e alguns SAP add-ons Estes patches ficam disponveis para download no sapnet (ou atravs de download via OSS a partir da SPAM). Para simplificar a sua implementao, a SAP empacota umas 3 vezes ao ano os Hot Packages, SPAM updates e LCPs em um CD que enviado para o cliente. O SAP Patch Manager (transao SPAM) a ferramenta utilizada para aplicar os patches no ambiente R/3 e dever ser executada no client 000 por um usurio que possua todos os privilgios (SAP_ALL) porm no dever ser o DDIC ou o SAP*. A SPAM fora a aplicao dos patches na ordem correta e obriga a um aceite em cada aplicao antes de aceitar a seguinte, forando desta forma a uma verificao da aplicao pelo cliente. O processo de aplicao dos patches deve ser efetuado em todos os sistemas do landscape. Caso se efetuem adjustments pela SPAU durante a aplicao, os mesmos podero ser salvos em change requests para posterior import nos demais sistemas, evitando a utilizao da SPAU mais de uma vez. Ao longo da utilizao e conseqente identificao de problemas nas funcionalidades do sistema, pode ser necessrio aplicar manualmente no R/3 correes disponibilizadas em notas no OSS. Estas notas (porm nem todas) sero posteriormente agrupadas em Hot Packages. Qualquer nota dever

50

R/3 Spool and Print

As definies de impressora so client independents, ou seja, basta definir a impressora em um dos mandantes para que todos possam utiliza-la. De preferencia aos clients mais nobres de cada um dos sistemas R/3. As principais transaes deste captulo so SP01 e SPAD.

R/3 Spool System

O R/3 possui diferentes formas de enviar documentos atravs de seus sistemas de spool. Um documento formatado, que pode ser uma impresso, um fax ou um EDI, representa uma message no sistema R/3 e, uma vez criada, estar liberada para impresso ou transmisso. As impresses no R/3 podem ser imediatas ou adiadas para sada posterior. Alm do message control, o R/3 possui uma combinao de programas de impresso e SAPScripts para produzir os documentos de impresso. Enquanto o programa de impresso obtm os dados a serem impressos, o SAPscripts especifica o layout do documento a ser impresso. Como o sistema R/3 um ambiente multiplataforma, foi criado um sistema interno de spool para interfacear com os diversos hosts nos quais o R/3 pode rodar. Atravs deste princpio o R/3 formata os documentos e requisita ao spool do sistema operacional que apenas repassa o documento para o dispositivo fsico de impresso que est alocado na porta paralela ou serial.

Spool and Output Requests

Um spool request criado quando um documento R/3 requisitado para impresso mas ainda no foi enviado para o dispositivo de sada. Os dados ficam armazenados em um interno do R/3. Um spool request formatado pelo spool work process e passa a ter um determinado formato para um dispositivo especfico, este formato nos chamamos de output request. Vrios output requests podem ser gerados a partir de um nico spool request, contendo cada um os atributos ou comandos especficos de um determinado hardware de impresso. Os spool requests gerados ficam armazenados em um repositrio denominado Temporary Sequential Database, ou TemSe. Este repositrio poder estar no banco de dados do R/3 ou em arquivos do global directory do sistema operacional (determinado pelo parmetro de profile rspo/store_location = db ou G e direcionado pelo parmetro rspo/files/root/G = $(DIR_GLOBAL) ). Os output requests so armazenados apenas como registros de controle. Os formatos de impresso uma vez gerados so repassados diretamente para o gerenciador de impresso do sistema operacional sem serem armazenados na base de dados.

Spool Work Process

Quando uma requisio de impresso de um spool request efetuada, um output request especfico 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. Uma vez formatado, o dado repassado diretamente para o spool do sistema operacional para que o encaminhe para o dispositivo endereado. Para formatar corretamente a sada, alm do driver especfico do dispositivo o R/3 utiliza informaes referentes ao character set utilizado e comandos especficos do dispositivo para formatao dos dados.

Local and Remote Printing

Os output requests formatados so repassados para os dispositivos atravs de strings de impresso. Quando se utiliza o mtodo Local, os dados so repassados diretamente para o spooler

51

do sistema operacional da mquina onde o spool work process que cuida de envia-los, seja para uma impressora conectada diretamente ao host ou atravs da rede. o mtodo mais rpido, uma vez que a tarefa de gerenciamento do string at o dispositivo de sada fica a cargo do sistema operacional, liberando o work process desta tarefa. Evite utilizar o host onde o sistema R/3 est rodando como o host que controla esta fila de impresso e possui uma impressora ligada fisicamente pois isto vai consumir recurso do sistema operacional. Existem cinco mtodos de acessos, a saber : L, utilizado onde o output request passado para o gerenciador de impresso do sistema operacional (do tipo line command). O mais comum ser utilizado no ambiente unix mas tambm pode ser utilizado no ambiente Windows NT. Os comandos a serem utilizados para imprimir e para verificar a fila podem ser redefinidos atravs dos parametros rspo/host_spool/print e rspo/host_spool/query, respectivamente C, utilizado onde o output request passado para o gerenciador atravs de call a bibliotecas especficas 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 impresso no front-end e quem formata o output device o dialog work process Remote printing consiste na transferncia dos output requests diretamente para os dispositivos remotos. Neste caso o spool work process fica responsvel pela negociao com o dispositivo atravs da rede. Este mtodo de acesso remoto menos otimizado por onerar o work process gerando possveis contenes na impresso. O spool work process fica preso at que ele consiga passar todas as informaes para o spooler remoto (ou saplpd) que eventualmente fica esperando o buffer da impressora, ou seja, o spool work process fica preso at que a maior parte da impresso fsica seja feita. A transmisso remota feita atravs de lpd (line printer daemon) e a SAP prov o programa SAPLPD para as plataformas que no possuem este protocolo standard. Devemos utilizar este mtodo somente quando a rede for muito rpida e muito confivel. Os mtodos de acesso so : U para os ambientes baseados no unix e impressoras de rede S para ambientes windows 9x com saplpd

Spool Administration
A transao SPAD utilizada no R/3 para a administrao de spool. As impressoras (output devices) so definidas especificando o mtodo de acesso (local L ou C - ou remoto U ou S para unix e windows respectivamente ) e suas caractersticas (device type, spool server, print server, atributos documentacionais, etc.). Para impressora remota devemos sempre utilizar o nome do print server no formato UNC //<host_name>/<printer_share_name>. Na verso bsica da SPAD podemos definir output devices, spool servers, access methods e destination hosts. Podemos tambm verificar a instalao, deletar spools antigos, verificar a TemSe e acionar SP01.

Frontend Printing
A impresso frontend no R/3 permite que usurios enviem output requests para impressoras que no foram definidas como output devices no R/3. o denominado mtodo de acesso F. Caso a estao do usurio seja um PC windows, o request enviado para um SAPLPD rodando na estao do usurios. Se o SAPLPD no estiver rodando, ele iniciado e manipula os requests e os envia para Neste mtodo de acesso o processamento do spool efetuado pelos prprios dialog work processes, no havendo necessidade de encaminhar o request para os spool work processes. Para definir uma impressora frontend para as estaes windows, alm de especificar o mtodo de acesso F, necessrio definir o device type SWIN (qualquer impressora com device instalado no windows) e o host printer dever ser __DEFAULT. Este mtodo dever ser evitado em sistemas produtivos por utilizar os work processes para tarefas que deveriam estar reservadas para os spool work processes alm de prender o dialog work process at que todos os dados da impresso sejam passados para a estao onde est o frontend e o saplpd.

52

Logical Spool Servers

Logical spool server uma camada que permite mapear spools lgicos para fsicos, permitindo efetuar o switch dinmico e balanceamento dos servidores. Um real spool server no ambiente R/3 uma instncia com pelo menos um spool work processes definido. Este mecanismo de definio lgica permite efetuar o switch facilmente entre servers reais que esto indisponveis sem interrupo do servio de impresso para os usurios. Como estas definies so configuraes do ambiente e portanto podemos utilizar o mecanismo de transportes de change requests do R/3 possvel definir toda uma arquitetura de impresso em um ambiente e posteriormente transporta-la para os demais sistemas do landscape.

Spool Request Management

O spool requests gerados no sistema devem ser gerenciados pelo administrador para garantir a disponibilidade do ambiente. O programa RSPO0041 deve ser schedulado em todos os sistemas para efetuar o trabalho de housekeeping e eliminar spools antigos do sistema. A transao SP01 o spool request viewer, que permite aos usurios ver seus requests e requisitar outputs ou eliminar spools. Administradores com autorizaes apropriadas podem ver todo SPAD ou o programa RSPO0043 pode ser utilizado para checar a consistncia entre os spool requests, output requests e output datas so consistentes cada um por si e as referencias cruzadas entre eles. A verificao de problemas associados com os spool requests pode ser efetuada tanto pela SP01 quanto pela SM21 ou ST22. Existem objetos de autorizao especficos para diversas operaes de spool no R/3, seja protegendo determinados dispositivos de sada (S_SPO_DEV) ou limitando o poder de gerenciamento (S_SPO_ACT e S_ADMI_FCD) . O objeto S_SPO_PAGE limita o nmero mximo de pginas que um usurio pode imprimir em um determinado dispositivo. Para que esta autorizao tenha efeito necessrio ativar o parmetro de profile rspo/auth/pagelimit=1.

53

R/3 Output Management

Atravs da opo de administrao estendida na SPAD, uma srie de funes avanadas podem ser escolhidas tais como : definio de device types, print controls, formats, page formats, OMS e character set.

Device Pools
O conceito de device pools permitir que se defina um pool de dispositivos de sada que podem ser referenciados atravs de um nico nome. Device pools so definidos especificando mtodo de acesso P e a lista dos dispositivos que o compem. Output requests podem ser enviados para todos os dispositivos que compem o pool simultaneamente ou pode-se requisitar que o sistema efetue o balanceamento de carga entre os dispositivos de sada da lista. Os dispositivos que compem a lista de 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 o gerenciador de impresso do sistema operacional tem bom tempo de resposta pois para balancear a carga 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 impresso que podem se fazer necessrios em ambientes complexos. Esta comunicao efetuada atravs do XOM-API. Atravs da definio de um objeto real de OMS (ROMS) e de pelo menos um objeto lgico OMS (LOMS), os spool requests de um sistema R/3 podem ser passados para o sistema externo. Os devices no ambiente R/3 que sero gerenciados pelo sistema externo OMS so definidos com o

Spool Server and Requests Management

Qualquer instncia R/3 que possui spool work processes denominada um spool server. O R/3 permite a definio de um alternate spool server que pode assumir as tarefas de um spool server principal. 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 impresso. O sistema R/3 permite que se classifique os servidores e os dispositivos em categorias (High volume, Production, Desktop e Test) o que faz com que o sistema envie uma mensagem de warning quando se efetua o assign de um determinado dispositivo com um server incompatvel. Os requests enviados para um determinado spool server caem em uma fila de spool e so processados sequencialmente. Quando o server possui mais de um spool work process, os requests so manipulados paralelamente de forma que determinado request da fila poder ser enviado para um dispositivo antes de outro documento pesado que ainda esteja sendo formatado. Caso se defina um dispositivo com a opo de sequential request procesing, os output request para o dispositivos sero serializados. Esta definio pode causar impacto em todo o sistema de impresso, j que durante a presena de requests para o device, um determinado spool work process fica reservado para processar a fila do device que possui a caracterstica de processar os requests sequencialmente. Para permitir que os usurios acompanhem o andamento de seus requests, os spool work process questionam os devices sobre o sucesso das operaes. Uma vez que durante este tracking o spool permanece aguardando uma resposta, isto pode ser particularmente problemtico para impressoras remotas ou com baixa performance na rede. Esta opo pode ser desabilitada para um dispositivo de sada especificando a opo no longer ask for print requests in host spool. Ao se especificar o atributo monitoring using monitoring infrastructure, o device pode ser monitorado atrvs da rvore de MTEs do CCMS. Alm das opes da jenela de manuteno do device temos ainda os parametros para controle de time-out e retries (rspo/tcp*).

54

Non-Standard Printers
Quando um determinado dispositivo de sada no possui device padro no R/3, possvel criar um driver personalizado para o dispositivo atravs da especificao de alguns objetos. A transao SPAD, em extended admin, fornece todos os mecanismos para formatar e testar o drive a ser utilizado pelo novo dispositivo. Antes de definir um novo dispositivo, verifique no OSS se j no existe disponvel o novo driver para ser baixado do sapservX. Se for necessrio criar realmente um novo driver cpie um j existente e altere o que for necessrio, sempre tentando manter o mais prximo do

Character set
O character set especifica os cdigos internos armazenados no spool request e seus respectivos ASCII que sero impressos. um de para. Cada caracter tem um cdigo interno no R/3 (nenhuma relao com o ASCII), cuja lista pode ser visualizada atravs da SPAD (Full Administration SAP characters). possvel acrescentar caracteres nesta lista, utilizando os cdigos 9000 a 9999. Cada tabela de character set disponvel transcreve este cdigo interno R/3 para um determinado ASCII. Para adapter uma determinada tabela, necessrio inicialmente copia-la e ento efetuar as alteraes na cpia e salvando posteriormente as alteraes 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 formulrios que no so padres necessrio 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 nmero de linhas por pgina, entre outros dados. Para definir format actions, ou seja, como determinado dispositivo manipula um determinado formato de impresso, necessrio editar o dispositivo de sada e acrescentar na sua opo de format as sequencias de caracteres para efetuar as operaes de impresso (printer initialization, new line, skip page, 12 char/inch, etc.)

Print controls
Os print controls determinam como um determinado dispositivo efetua determinadas operaes, como por exemplo imprimir em bold. Print controls so especficos de cada device e durante a formatao so convertidos para determinadas sequencias de caracteres. A sequencia correta deve ser obtida no manual da impressora, aps ter certeza que a SAP no disponibilizou driver para este device.

Message Control and EDI

O message control utilizado no R/3 para troca de informaes entre parceiros envolvidos em uma determinada regra de negcio. Os documentos gerados (EDI, fax, impresses, etc.) so normalmente gerados atravs de exits especficas dentro programas R/3 que so chamadas para formatar a sada desejada. Dependendo da customizao efetuada, o documento gerado enviado como parte da transao ou fica pendente para posterior envio. O EDI, Electronic Data Interchange, a troca de mensagens de negcio entre dois sistemas atravs de interfaces standard. A SAP no fornece um subsistema EDI no R/3, mas prov uma interface aberta para estes sistemas se conectarem. Esta interface baseada em Intermediate Documents, ou IDOCs. No R/3 todos os dados transferidos por EDI so transferidos atravs de RFCs entre os sistemas envolvidos.

55

SAPconnect
O SAPconnect uma camada que permite a comunicao do R/3 com outros sistemas externos, tipo fax ou mail servers. A conexo do R/3 com sistemas externos normalmente requer a especificao de interfaces externas, porm a conexo entre dois sistemas R/3 via SAPconnect pode ser feita diretamente. Estes adapters externos devem ser fornecidos por cada fornecedor interessado em se conectar com o sistema R/3. A SAP fornece um adapter para o Microsoft Exchange Server que pode ser configurado para integrar as duas ferramentas. Para configurar o SapConnect utilize a transao SC0T. Para maiores informaes sobre o SapConnect utilize as notas 34705 e 92950.

56

Database Fundamentals
Oracle Overview

Uma instncia oracle o conjunto voltil de processos e estruturas de memria. Um banco de dados oracle um conjunto de arquivos de dados que so manipulados pela instncia oracle. Podemos dividir o Oracle em uma srie de estruturas de memria. A mais famosa entre elas a SGA (system global area) e ela um grande grupo de buffers de memria compartilhados, a saber : shared pool, database buffer cache e redo log buffer. Para acessar estas estruturas existem os processos que executam uma srie de tarefas de manuteno da instncia. Cada processo distinto, possui uma funo especfica, executado em background e assincronamente. Os principais processos so : pmon, smon, dbwr, lgwr, reco, lck ckpt, snp e arch. A shared pool uma poro de memria compatilhada que contm as reas chamadas de shared sql, library cache, data dictionary cache e sequence cache. Todas participam do processo e so as estruturas que contm os sqls que esto sendo execudados pelos mltiplos usurios. Essas reas contm ainda os comandos na forma interpretada e texto, a anlise dos comandos com os respectivos planos de execuo, informaes de dicionrios e geradores de nmeros sequenciais. O principal objetivo da shared pool viabilizar que um comando sql seja utilizado por diversos processos distintos. Uma nica shared sql area pode ser compartilhada por diversas aplicaes que usam o mesmo comando deixando mais reas em memria disponvel para os outros usurios e melhorando a performance de execuo de um comando, j que o plano de execuo estar definido

57

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 contm os blocos livres, aqueles que esto em uso e inclusive blocos alterados. Quando um processo servidor precisa 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 nmero especfico de blocos so pesquisados sem encontrar um bloco livre. O redo log buffer armazena todas as alteraes feitas em um banco de dados em memria. Todas as entradas de redo log neste buffer so escritas nos arquivos de redo log, que so usados para a

O Oracle cria um conjunto de processos que rodam em background para cada instncia, Esses processos executam diversas tarefas. Entre eles podemos destacar : DBWR O processo database writer escreve os blocos modificveis do database buffer cache para os arquivos de dados. Os dados mais antigos so escritos em primeiro lugar. O dbwr adia ao mximo a escrita dos blocos alterados para otimizao de I/O em disco para evitar aquela que 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 so armazenados em memria no redo log buffer, e no momento em que uma transao for efetivada ou o redo log estiver com preenchimento de pelo menos um tero, o lgwr 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 ento atualiza os headers dos control files e dos datafiles. SMON O processo de system monitoring efetua a recuperao da instncia em caso de falhas, durante a uma inicializao. Ele tambm limpa os segmentos temporrios que no esto sendo usados, liberando memria e recupera qualquer transao pendente no caso de uma falha fsica. Simplificando, o smon um monitor das aes do sistema detectando e corrigindo possveis falhas no sistema PMON O processo monitor executa a recuperao do processo de um usurio em caso de falhas. Ele limpa a rea de memria e libera os recursos que o processo usurio estava usando. Simplificando, o pmon um monitor das aes dos usurios detectando e corrigindo possveis falhas nos processos dos usurios ARCH O processo de archiver copia os arquivos redo log para fita ou mesmo outro disco, no momento em que um deles torna-se completo. Este processo geralmente est presente quando o banco de dados esta sendo utilizado no modo archivelog. RECO O processo de recover usado para resolver transaes distribuidas e pendentes. LCKn Os processos de lock (lckn) so usuados para controlar o lock entre instncias em uma configurao oracle parallel server. Dentro de uma instncia Oracle existem vrios processos que so criados quando a instncia entra em funcionamento. Eles se dividem em dois grupos : Dedicated shadow processes: que so os processos criados no Oracle para as conexes dos work processes. Existe uma relao de 1 para 1 entre estes processos e os work processes da instncia R/3 e eles s aparecem quando o R/3 est no ar Shared processes: so os processos criados no Oracle para gerenciamento e funcionamento da instncia que ir controlar o banco de dados. Eles tem atividades especificas e trabalham para a manuteno da instncia como um todo. Os dados so armazenados em datafiles organizados em blocos de 8k (8192 bytes). Estes blocos so carregados para uma rea comum da memria principal denominada database buffer pool. Sempre que uma leitura feita pelo menos dois blocos so carregados, um para header e outro para dados. Cada bloco do DB buffer pool contm um header com os dados das transaes que podero compartilhar o mesmo bloco. O nmero de entradas no header configurado pelo parmetro INIT<SID> do .ora. As alteraes efetuadas nos dados do banco de dados so feitas inicialmente no database buffer com a imagem anterior copiada para a rea de rollback e refletidas na redo log files garantindo com isso a segurana transacional dos dados. Estes redo log files so espelhados por questes de segurana. Os control files no so espelhados mas deve possuir mais de uma cpia, tambm por motivos de segurana. Para verificar quantos control files existe utilizem a view v$controlfile atravs

58

de sql ou da ST04. Para criar mais uma cpia do control file, copie o arquivo para o local desejado e altere o parametro control_file no initSID.ora acrescentando o novo caminho, tudo isto com o oracle no estado NoMounted. Se for necessrio acessar o controlfile com o banco for a do ar o estado do banco deve ser Mounted. Os comandos SQL executveis ficam armazenados em outra rea da memria denominada Shared SQL area que tambm parte do shared pool. Nesta rea temos ainda Library cache com os cursores de execuo dos comandos SQL e a Row cache, com informaes dos objetos no dicionrio Oracle. Os work processes do R/3 se conectam com os shadow processes no Oracle com o usurio SAPR3. Caso esta conexo caia, os work processes tentam reconexo com o Oracle seguindo a parametrizao feita nas profiles (default ou instance) atravs das variveis rsdb/reco_trials e rsdb/reco_sleep_time. Uma instncia Oracle aceita 3 tipos de conexes de seus clients: dedicated, que a utilizada pelo R/3, Combined e Multi-thread. Os principais problemas de performance esto associados a shared pool (shared sql area e row cache), ao uso dos data buffers e a redo log. Outro ponto de preocupao o acesso a disco, sua estruturao de alocao e a possvel conteno causada pelo acesso ao disco. Obs: Conceito Importante - O check point uma marca de sincronismo entre todos os datafiles e a online redo logfiles. Sempre que ocorrer um switch no online redo logfiles gravado um check point para garantir a segurana e sincronismo. Se o banco estiver em archivelog mode, a offline redo logfile archivada no diretrio saparch logo aps o switch.

Starting and Stoping the Database

O banco de dados Oracle passa por trs fases distintas ao ser inicializado: Nomount phase: a instncia Oracle construda (shared pool) a partir das informaes parametrizadas no arquivo init<SID>.ora Mount phase: o control file aberto e suas informaes referentes aos logs e datafiles so obtidas mas no podemos acessar os datafiles atravs de um sql. Open phase: todos os files so abertos. Se o ltimo shutdown no foi realizado com sucesso, o sistema efetua um rollback das transaes inflight e retorna todos os arquivos ao ultimo ponto de sincronismo (check point). Os processos podem ento comear a submeter requests ao banco de dados aberto. O shutdown pode ser realizado em trs formas distintas tambm, a crittio do administrador: Shutdown Normal: O sistema para de aceitar novas conexes e aps o encerramento de todas as conexes j efetuadas os datafiles so fechados, o database desmontado e a instncia finalmente sai (shutdown) Shutdown Immediate: Apenas os comandos j em andamento so terminados. Todas as conexes so derrubadas atravs do PMON e caso exista alguma transao inflight, feito um rollback antes da instncia sair atravs de um shutdown consistente, ou seja, um check point gravado. No sapdba ainda temos shutdown immediate force que retira o R/3 antes de derubar o oracle. Shutdown Abort: Em casos de emergncia apenas, este comando derruba todas as conexes e retira a instncia do ar colocando o banco de dados em um estado de inconsistencia. O prximo startup precisar efetuar um recovery das transies que permanecero inflight, at que a base volte a ser consistente (roll foward)

Oracle Shared Processes

Uma instncia Oracle possui trs 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 para os database data files. Checkpoint process (CKPT): que acelera o processo de gravao dos checkpoints na

59

Logwriter (LGWR): que grava em modo sncrono as alteraes efetuadas nos data buffer e logadas na redo log buffer para os online redo log files

Um banco de dados em produo 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 instncia. Os arquivos do online redo log files funcionam de forma cclica e a cada switch, o file que estava sendo usado transferido para a rea de archive. O parmetro da init<SID>.ora, log_archive_start=TRUE ativa o processo de archive na instncia. O processo ARCH se baseia nos parmetros log_archive_dest (default $ORACLE_HOME/saparch) e log_archive_format para gerar o archive na offline redo log area. Quando o online redo log file foi transferido com sucesso, o respectivo file fica disponvel para ser sobrescrito no processo cclico de utilizao dos files. Caso no haja espao disponvel na offline redo log area para a gravao do novo file, o online redo log file no liberado e consequentemente ir travar a instncia quando o ciclo requisitar novamente o online redo log file, devendo a rea ser liberada para que o Oracle continua com o seu funcionamento normal.

R/3 Oracle Structure

A estrutura de tablespaces do R/3 no Oracle obedece a um padro especfico de nomes: PSAP<name>[D para data e I para index]. Por exemplo, se uma rea de dicionrio do R/3 ficar armazenada nos tablespaces PSAPDDICD (dados) e PSAPDDIC (ndices). Esta nomenclatura obrigatria para o uso do R/3 e suas ferramentas. As tablespaces que normalmente so criadas nas instalaes so : Prefix Tablespace Ext. Meaning SYSTEM Oracle DDIC PSAP PSAP PSAP PSAP PSAP PSAP PSAP PSAP PSAP PSAP PSAP PSAP PSAP PSAP ROLL TEMP EL<release> ES<release> LOAD SOURCE DDIC PROT CLU POOL STAB BTAB DOCU USER1 D ou I D ou I D ou I D ou I D ou I D ou I D ou I D ou I D ou I D ou I D ou I D ou I D ou I D ou I Segmentos de rollback Area temporaria normalmente utilizada para sort Mdulos do ambiente de desenvolvimento Fontes do ambiente de desenvolvimento Mdulos das janelas e relatrios Fontes das janelas e relatrios Dicionrio abap Tabelas do tipo log Tabelas cluster Tabelas pool Tabelas de dados mestres ou transparentes Tabelas de dados transacionais ou transparente Documentaes, sapscripts e sapfind Tabelas do cliente

Owner Oracle rdbms Oracle rdbms Oracle rdbms Basis Basis Basis Basis Basis Aplicaes Aplicaes Aplicaes Aplicaes Aplicaes Aplicaes

Os datafiles que compem o tablespace tambm devero possuir uma estrutura prpria 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 acima tivesse 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 ndices obedeceriam o mesmo critrio, apenas o nome seria ddici, e no ddicd (.../ddici_1/ddici.data1) Todos os objetos alocados nos tablespaces PSAP... pertencem ao usurio SAPR3. Os tablespaces SYSTEM, PSAPROLL e PSAPTEMP possuem objetos que pertencem aos usurios SYS ou ao SYSTEM. O usurios que se logam em um sistema R/3 no possuem objetos nas tabelas do Oracle, apenas armazenam linhas nas tabelas do banco de dados atravs da conexo efetuada com o user SAPR3 A estrutura de diretrio do Oracle com o R/3 obedece a seguinte hierarquia : /orant (oracle home)

60

database: contendo as profiles utilizadas pelo Oracle e pelo SAP (init<SID>.ora, init<SID>.sap, etc.). bin: executveis Oracle (no NT ele est no /orant/bin) /net80/admin: arquivos de configurao 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 reorganizaes, 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 trs arquivos de parametrizao: init<SID>.ora: parametrizaes da instncia Oracle init<SID>.dba: parametrizao do sapdba init<SID>.sap: parametrizao das ferramentas BRBACKUP e BRARCHIVE Vrias variveis de ambiente parametrizam o usurio <sid>adm : ORACLE_SID=<SID>: nome da instncia DBS_ORA_TNSNAME: seta o <SID> do banco que ser conectado atravs do tnsnames.ora ORACLE_HOME: o diretrio home do oracle (/oracle/<SID>) SAPDATA_HOME e SAPDATAn: aponta para diretrios especficos contendo dados Alm dos usurios Oracle SYS e SYSTEM, existem os seguintes usurios no unix : ora<sid>: usurio unix pertencente aos grupos dba e oper <sid>adm: usurio unix pertencente ao grupo oper OPS$<sid>adm: usurio definido no oracle como identified externally <sid>adm: usurio NT pertencente ao grupo ora_SID_dba sapservice<sid>: usurio NT pertencente ao grupo ora_SID_oper OPS$<sid>adm: usurio definido no oracle como identified externally

Quando o parmetro OS_AUTHENT_PREFIX=OPS$ codificado no init<SID>.ora, isto indicar que o usurio <sid>adm (OPS$<sid>adm) poder se conectar ao oracle sem autenticao. Isto ser necessrio para determinadas tarefas restritas de administrao. Neste caso a autenticao do fica a cargo do sistema operacional. O mecanismo de conexo dos work processes com o shadow process no Oracle funciona da seguinte forma: o work processes tenta a conexo atravs do usurio SAPR3/SAP. Caso a senha tenha sido alterada, o que aconselhvel, a conexo recusada e o work process tentar uma conexo atravs do usurio OPS$<sid>adm (que no exige autenticao) e acessa a tabela SAPUSER (cujo owner o prprio user OPS$<sid>adm) e atravs dela possui a senha para o

O programa chdbpass (no unix) quando utilizado para alterar a senha do usurio SAPR3 j grava nesta tabela OPS$<sid>adm.SAPUSER a nova senha. O NT que no possui este programa disponvel o que torna necessrio a incluso manual da senha na tabela quando se altera o usurio via alter user. A conexo remota dos work processes entretanto com o banco R/3 atravs do user OPS$ somente se dar se o parmetro REMOTE_OS_AUTHEN estiver setado para TRUE.

NET8 Basis
A comunicao dos work processes com o Oracle se d atravs de comunicao TCP/IP atravs da rede. A camada Oracle que interpreta e aceita estas conexes o NET8. Para que o NET8 aceite

61

conexes atravs da rede, o listener do Oracle precisa estar ativo. O utilitrio lsnrctl80 utilizado no database server para dar start e stop no processo tnslsnr que executar o servio. .../net80/admin do oracle configuraro o servio NET8: tnsnames.ora: contm a lista dos servios para todos os bancos de dados acessados na rede sqlnet.ora: contm, no lado client, informaes do default domain alm de parmetros opcionais de diagnsticos usados para trace e logs do client listener.ora: usado no database server e contm Oracle system Ids com o quais o Oracle poder receber conexes e parametrizaes do listener

Database Monitoring
Vrias transaes so utilizadas no R/3 para monitorar a base de dados: A DB16 um system check monitor, a DB12 o monitor de backup, a DB02 a transao utilizada para monitorar os objetos (tableas, ndices, tablespaces) do banco. Alm destas, a ST04 o monitor de performance e a DB14 o monitor das logs das atividades administrativas do banco.

62

Backup Estrategy
Database Backup
A estratgia de backup da base de dados necessria para garantir a recuperao de uma base de dados que pode falhar por diversos fatores, sejam fsicos (crash de disco), lgicos (operao indevida nos aplicativos) ou fatores externos (fogo, agua, greve, etc). Atravs de cenrios que iremos estudar, possvel fazer full recoveries (recuperao total) dos data bases ou ainda recuperaes point in time (recuperao total em um ponto do tempo passado) a partir de uma boa estratgia de backup. Operaes de recovery, por serem crticas, exigem documentao detalhada, estratgia estudada alm de skill especfico dos administradores de banco de dados. Ou seja, antes de tomar qualquer ao aps um problema, tenha certeza do que est sendo feito e de que a ao a melhor opo entre outras analisadas. Os files que compem uma base de dados Oracle podem ser divididos em cinco grupos: Os data files so os arquivos que contm os dados da aplicao propriamente ditos. aconselhvel que sejam protegidos por espelhamento (RAID V ou superior) Os online redo log files so os arquivos onde so gravadas as logs de transaes no banco de dados e so espelhadas por definio atravs das mirrlogs Os control files so os arquivos que possuem as informaes de controles referentes aos datafiles e a base de dados. O Oracle mantm cpias deste file em mais de um filesystem do ambiente, definido por parmetro na initSID.ora Profiles so os arquivos de configurao da instncia oracle Offline redo log files so as cpias 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 online redo log files, os control files e as profiles. Um processo de backup do offline redo log file copia os offline redo log files e as profiles para outro dispositivos. Para garantir a integridade fsica da base de dados ou seja, garantir que as tabelas e blocos estejam fisicamente ntegros necessrio efetuar logical data checks atravs de ferramentas oracle como o utilitrio dbv (database verify). Temos integridade das fitas backupeadas necessrio efetuar um physical data check, que verifica a integridade fsica das fitas gravadas atravs da leitura dos dados backupeados na fita.

Backup Types
Um processo de backup offline executado com a instncia em shutdown e os seguintes arquivos so 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 instncia ativa e os seguintes arquivos so copiados: data files, control file e profiles. Estas cpias online no so consistentes, j que o processo de update no banco continua sendo efetuado pelos usurios. Um recovery a partir de um online backup somente tem sentido com o cruzamento das logs (redo logs) geradas no decorrer do processo. Um processo de partial backup pode ser utilizado para diminuir o tempo gasto no processo. Neste caso apenas alguns tablespaces sero copiados em cada dia at fechar um ciclo. Independente do processo utilizado (offline ou online) este backup inconsistente e precisa das offline redo log de todo o ciclo para permitir um recovery do database. Outro processo para diminuir a janela de backup atravs do paralelismo do backup com a utilizao de vrios drives de fita. Este processo reduz significantemente o tempo de backup e restore, sendo porm caro pelo hardware envolvido.

63

Backup and Recover Diagram

Backup

ArchiveLog

NoArchiveLog

On-Line

Off-Line

Complete Recover

Incomplete Recover with reset log

Reset

Data Loss
Vrias so as causas que podem causar a perda de dados em uma base de dados. podem ocorrer pela deleo indevida de objetos do banco de dados (um data file), um drop em uma tabela ou ainda por erro de aplicativo que provoca a perda de dados. Erros lgicos so recuperados um full database restore seguido de um point in time recovery at o momento imediatamente anterior a causa da perda da informao. A ausncia de um offline redo log file durante um processo de recovery causar a perda de todas as informaes subsequentes, j que o processo no permite a aplicao dos offline seguintes ao que foi perdido. Por este motivo importante a manuteno de pelo menos redo log files em dispositivos diferentes para garantir uma recuperao com uma salva-guarda de contingencia. Uma outra causa de necessidade de recuperao o chamado disaster recovery, efetuado por causas fsicas, como por exemplo um crash de disco. A manuteno de cpias de backup em cofres garantem inclusive a possibilidade de recuperao de todo o ambiente computacional em caso de perda total das instalaes fsicas do cpd.

Backup Recommendations
Alteraes nas estruturas dos arquivos afetaro os restores subsequentes, como ocorre por exemplo quando um data file acrescentado a base de dados. Processos como este que causam a backup adicional imediato do banco de dados para que o processo de recuperao, se houver, no seja afetado pelo diferente estado do banco de dados. O ponto crtico de uma alterao estrutural do banco de dados a necessidade de ter ao menos uma cpia do novo datafile e a estrutura gerada no control file. Sem isto impossvel recuperar o banco na nova estrutura ou fazer um log-foward aps este evento.

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

64

ou seja uma cpia a cada dia til do ciclo. importante ainda que tenhamos em cada ciclo pelo menos um backup offline, um check de consistncia do backup e check dos datafiles do banco de dados. Esta recomendao bsica, sendo o ideal fazer tudo isso pelo menos uma vez a cada semana. recomendvel tambm que os arquivos do backup online fiquem em fitas diferentes do backup do offline redo log. Isso viabiliza novas alternativas para os planos de contingencias caso as fitas tambm apresentem problemas.

Final Recommendations
Utilize as ferramentas providas pela SAP para efetuar o backup (BRBACKUP e BRARCHIVE) e tenha certeza que elas esto configuradas corretamente. Para um evetunal restore do banco de dados utilize a ferramenta BRRESTORE. Estas ferramentas que efetuam o backup e o restore trabalham integradas ao sapdba e se baseiam em logs prprias gravadas no sistema operacional para direcionar o seu funcionamento. bom lembrar que alm do banco de dados, necessrio manter backup consistente de outros objetos R/3, tais como archiving, interfaces, executveis e do sistema operacional. No adianta muito ter o backup da base de dados se no tivermos o R/3 e o Oracle instalados e com os arquivos de

S a correta implementao de uma boa estratgia de backup a garantia para a recuperao do sistema sem perda de informaes em caso de falhas.

65

Scheduling, Performing and Monitoring Backups

Backup Tools Features
Para fazer um backup podemos utilizar uma das ferramentas : Transao DB13 - DBA Planning Calendar - onde possvel schedular backups peridicos em Utilitrio SAPDBA onde possvel ativar backups espordicos de forma interativa por menus e vrias outras operaes de administrao e operao do oracle BRBACKUP e BRARCHIVE onde e possvel realizar backups a partir de linha de comando

Backup profile parameters

Alguns dos parmetros podem possuir valores default definidos na profile init<SID>.sap, como por exemplo o tipo de compresso, comando para compresso, utilitrio para cpia, dispositivo a ser utilizado, etc. Os utilitrios brbackup e brarchive atualizam as tabelas SDBAD e SDBAH, checa o lock de fitas e gera logs especficas das atividades efetuadas sempre levando em conta a parametrizao feita neste arquivo.

tape_size Parameter
O parmetro tape_size da init<SID>.sap define o volume de dados que cabe no modelo de fita utilizado tanto para o BRBACKUP quanto o BRARCHIVE. Este parmetro importantssimo j que a sua m especificao pode causar mal funcionamento do processo de backup. Atravs da especificao do parmetro tape_size os utilitrios de backup (BRBACKUP e BRARCHIVE) calculam o volume de dados que pode ser enviado para cada fita, dimensionando desta forma o nmero de fitas que sero necessrias durante o processo. Quando mal dimensionado pode causar o desperdcio de mdia ou, pior ainda, erro no processo de gravao. O utilitrio dd utilizado no processo de cpia acusa erro quando atinge o end-of-tape. J o utilitrio cpio, desde que no esteja trabalhando em modo parallel, consegue passar os dados para um volume subsequente, porm este volume no ser reconhecido pelas ferramentas de gerencia de fitas por ter sido requisitado ao longo do processo e no possuir o arquivo de identificao da fita (.tape.hdr0). O ideal portanto que este 10% menor que a capacidade real da fita, como margem de segurana. Quando utilizamos compresso por hardware, o valor do tape_size dever ser ainda um pouco mais folgado, uma vez que a taxa de compresso varia dependendo do tipo de dado armazenado. A nota 8707 d todos os detalhes sobre esta especificao de tape_size. Para distribuir os files pelas fitas, o brbackup utiliza informao da dos files. Este clculo da taxa de compresso dever ser efetuado uma vez a cada ciclo atravs do comando . Quando utilizado tape stations com hardware compression, o parmetro compress_cmd da init<SID>.sap dever ser setado para compress b 12 c $ > $ (em unix). A compresso por software efetuada no diretrio 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 uma certa concorrncia nos datafiles. Os seguintes processos so efetuados durante o processo. Salva a sada de um backup control file em disco Obtm os files names que sero 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

66

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, porm o brbackup deixa a instncia no estado exato em que se encontrava no incio do processo (up ou down): Start no database, se o mesmo se encontra em shutdown Obtm os files names que sero 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 no for completo os online redo log no sero backupeados

Database Backup Check and Monitoring

Blocos de dados danificados no banco de dados somente so identificados quando o Oracle tentar manipular este bloco. O utilitrio dbv da Oracle efetua o check de um datafile quanto a estas integridades. Esta verificao lgica da integridade dos dados pode ser realizada em tempo de backup atravs . Este processo faz com que os files sejam lidos da fita aps gravados e transferidos para o diretrio de compress (compress_dir) onde so processados pelo utilitrio dbv da Oracle. O processo alm de detectar blocos corrompidos garante a disponibilidade da fita. aconselhado que seja efetuado uma vez por semana ou no mnimo uma vez no ciclo. Como este processo pelo menos duplica o tempo gasto no backup, possvel adiar a execuo do verify atravs de uma execuo posterior de uma simulao de BRRESTORE, que pode inclusive ser executado em outra mquina. (Para maiores informaes de datafiles corrompidos veja a nota 99962). A opo de verificao da integridade lgica (-verify use_dbv) verifica a integridade dos blocos Oracle porm no garante que o file gravado na fita seja idntico ao file existente no disco. Esta verificao da integridade fsica dever ser efetuada uma vez no ciclo, que ocorrer a nvel binrio com a especificao do parmetro (-verify ou w). Este processo de verificao fsica somente pode ser executado no processo de backup offline e tambm ir provocar a leitura da fita para que o file seja transferido para a rea de compress. Este processo duplica o tempo de backup e, diferentemente do anterior, no pode ser postergado para um posterior BRRESTORE. O BRBACKUP grava logs em files no diretrio sapbackup e nas tabelas SDBAH e SDBAD que devem ser checados constantemente. Os logs gravados obedecem a um padro prprio de nomenclatura (b<timestamp>.<ext>) cuja extenso depende do tipo de backup selecionado. As transaes DB12 e DB13 tambm permitem acompanhar a execuo dos backups

Offline Redo Log Files Backup

O processo Oracle ARCH responsvel pela movimentao as Online redo log files durante o switch de log. Estas logs so transferidas para a rea saparch e devem ser transferidas para fitas de tempos em tempos. Este processo denominado Offline redo log backup e efetuado pelo programa BRARCHIVE. 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 os redo log files : ARCHIVED: estado indicando que o file foi arquivado SAVED: indicando que uma gravao para fita foi efetuada COPIED: indicando que uma segunda cpia foi efetuada DELETED: indicando que o file foi deletado do diretrio

67

O BRACHIVE possui uma serie de opes 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 deleo seja efetuado automaticamente. Outra boa opo e a opo f (fillup) onde o brarchive grava os files e continua verificando a saparch de tempos em tempos. Qualquer offline que aparea ento gravado at que a fita esteja cheia. Como no BRBACKUP, devemos utilizar a opo verify ou w para efetuar um check fsico dos arquivos gravados e recomendado que seja efetuado uma vez no ciclo. A monitorao do processo de offline backup dever ser efetuado atravs da transao DB12 e atravs da monitorao do arch<SID>.log no diretrio saparch. Atravs da forar a gravao de mais informaes na log.

Log File Cleanup

Os logs gerados tanto pelo BRBACKUP quanto pelo BRARCHIVE so utilizados posteriormente pelo SAPDBA para tomar as aes corretivas e parametrizar o BRRESTORE. Estes files porm vo se acumulando nos diretrios e precisam ser eliminados de tempos em tempos. O SAPDBA possui clenup no s destes logs como tambm dos traces e logs geradas pelo Oracle e pelo prprio sapdba. A limpeza dos logs de backup e archive se baseia nos parmetros expir_period_* da init<SID>.dba. Estes parmetros devero ser adaptados de acordo com o ciclo de backup adotado na empresa. A chamada a estas funes poder ser executado interativamente via em linha de comando ou via algum utilitrio de agendamento do sistema operacional.

Freespace Administration
Os offline redo log files so transferidos para a rea de archive saparch atravs do servio Oracle ARCH. Se estes arquivos no forem backupeados para fita e deletados, a rea poder estourar, o que causa a parada do Oracle conhecida como archiver stuck. Neste caso a instncia para por no poder sobrescrever um online redo log file ainda no transferido para a rea de offline. Este problema somente ocorre se o ARCHIVELOG mode estiver ativado, o que padro em ambientes produtivos. Atravs da DB12 deve-se monitorar a rea livre no diretrio (ou atravs de df k) e tomar medidas preventivas (archive) antes que o problema ocorra. Outra soluo que pode ser adotada a definio de um arquivo dummy grande o suficiente para que, em caso de archiver stuck, ele possa ser removido dando ao sistemas mais alguns minutos enquanto se processa o archive. Caso o sapdba no mais responda a comandos, ative o brarchive via linha de comando

One-Run Strategy
A estratgia One-Run backup consiste em efetuar o backup e o archive em uma nica chamada ao br backup atravs da especificao de parmetros prprios ( Neste caso apenas uma fita do pool backup (volume_backup) utilizada para armazenar os dois backups. Esta estratgia porm s pode ser utilizada se o backup dos datafiles e todos os offline redo log files couberem em uma nica fita. A soluo neste caso o uso de paralelismo no backup (mais de um drive) ou ento adotar outra estratgia para o backup. Esta soluo possui o incoveniente dos datafiles e ds offline redo log files estarem na mesam fita. Alm disso, em caso de um archiver stuck ocorrer, esta opo no poder ser usada, j que o brbackup tentar se conectar com o banco que se encontra travado. ).

Further Documentation
Para maiores informaes sobre backup e recover, veja as notas 96896, 19909, 99088, 71058, 8707, 33630, 99962, 23345, 100400 e 83699.

68

69