Treinamento Basis Fase I

Introduo a BasisUnidade 01: IntroduoUnidade 02: Start e Stop R/3Unidade 03: Configurao da CCMSUnidade 04: Administrao e Backup do Banco de DadosUnidade 05: BD: Procedimentos diriosUnidade 06: Processamento em BackgroundUnidade 07: Administrao dos ClientsUnidade 08: Autorizaes no R/3Unidade 09: Impresso e SpoolUnidade 10: Monitorao do SistemaUnidade 11: SAP Online Service System

O que o SAP R/3???Systems, Applications, Products in Data Processing

IntegraoElementos Organizacionais, dados e processos so integradosIntegrao Tcnica e da AplicaoBanco de Dados comumEliminao de dados redundantesIntegridade dos dados

Flexibilidade com DisciplinaSAP R/3 permite que seu usurios parametrizem os diferentes mdulos de negcios para adaptar o sistema Empresa e realizar os melhores processosSAP R/3 pode ser executado em vrias plataformas de HardwareSAP R/3 permite configurar telas, processamento e relatriosPermite interface com softwares externos

Processamento InterativoVrios usurios podem alterar dados simultaneamente. O SAP R/3 controla estas alteraes.Os relatrios e outras transaes de negcios so atualizados on-line.O banco de dados gerenciado pelo SAP R/3 para garantir a consistncia dos dados, assim como as necessidades do negcio

Uso mundialSuporta uso em vrias lnguasPermite transaes em diversas moedasPossui funcionalidades especficas para cada pas como:- impostos- relatrios governamentais (balano)Possibilita utilizao multi-companhias

R/3Client / ServerABAP/4FIGestoFinanceiraCOControladoriaAMAtivoImobilizado.PSProjetosWFWorkflowISIndustrySolutionsMMGerenc.de MateriaisHRRecursosHumanosSDVendas &DistribuioPPPlanej.de ProduoQMGerenc.da QualidadePMManutenoIndustrialMdulos de Aplicao

Arquitetura Cliente/ServidorA arquitetura do sistema SAP R/3 baseado em three-tier client/server (cliente servidor trs nveis):- Apresentao- Aplicao- Banco de dados

LANDSCAPE

LANDSCAPEDesenvolvimentoQASProduo100 Sandbox200 Customizing300 Testes Gerais300 QAS300 Produo

Clients do R/3

LANDSCAPE

CPIA DE CLIENT

Administrao BasisUnidade 01: IntroduoUnidade 02: Start e Stop R/3Unidade 03: Configurao da CCMSUnidade 04: Administrao e Backup do Banco de DadosUnidade 05: BD: Procedimentos diriosUnidade 06: Logstica de SoftwareUnidade 07: Processamento em BackgroundUnidade 08: Autorizaes no R/3Unidade 09: Impresso e SpoolUnidade 10: Monitorao do SistemaUnidade 11: SAP Online Service System

Start / Stop do R/3Contedo:Processos e servios no ambiente R/3-WINDOWS-SQLStart e Stop de processos e procedimentosObjetivos:Explanar o conceito de serviosDescrever os processos de start e stop do R/3Analisar os erros durante o processo de startup e shutdown

Servios R/3SAP:SAP_SAPOSCOL

SQL: MSSQLServer

Start / Stop R/3: Administrador Stop: 1 - Logar como usurio adm no servidor 2 Stop no SAP 3 Stop no SQL Start: 1 - Logar como usurio adm no servidor 2 Start no SQL 3 Start no SAP

Start / Stop - SQL ServerMenu: Iniciar Programs Microsoft SQL Server Service Manager

Start / Stop SAP R/3Menu: Iniciar Programs SAP System Management Console

Starting R/3: Seqncia do Processo de Startup

Seqncia de Leitura dos Parmetros

Logs e Trace do Banco de Dados

Logs e Traces do Windows NT

Logs de Startup e Trace do R3

Razes para Downtime do R/3

Procedimento de Stop do R/3Verifique se existem jobs de backgrounds ouBatch input (SM37/SM35) em execuoVerifique o status de update com SM13Envie mensagens com a SM02Verifique os usurios logados com a SM04Verifique os processos em execuo na SM50Verifique as interfaces externas

Administrao BasisUnidade 01: IntroduoUnidade 02: Start e Stop R/3Unidade 03: Configurao da CCMSUnidade 04: Administrao e Backup do Banco de DadosUnidade 05: BD: Procedimentos diriosUnidade 06: Processamento em BackgroundUnidade 07: Logstica de SoftwareUnidade 08: Autorizaes no R/3Unidade 09: Impresso e SpoolUnidade 10: Monitorao do SistemaUnidade 11: SAP Online Service System

Configurao da CCMSContedo:Configurando a CCMS (Computer Center Management System)Inicializando e finalizando uma instance com a CCMSObjetivos:Importar e manter as profilesDefinir os operation modesManter as definies da instanceAgendar os operation modesInicializar e finalizar uma instance com a CCMS

Configurando a CCMSImportar e dar manuteno nos profiles do R/3Definir operation modesCriar as definies das instancesAdaptar as definies e dos operation modesManter cronograma para as operaes do sistema

RZ10: Manuteno de ProfilesUsada para manter todos os profiles do R/3:Start profileDefault profileInstance profilePermite mudar os parmetros do profile usando basic mode ou extended modeProvidencia gerenciamento de versesPermite listar os parmetros ativos do application server

Profiles do R/3

Mantendo as Profiles do R/3

Mudando Parmetros de Profile do R/3

Operation Modes: Conceitos

Alternado um Operation Mode (1)

Alternado um Operation Mode (2)

Criando Operation Modes

Alternado Operation Modes

Scheduling Operation Modes

Alternando Operation Modes Manualmente

Administrao BasisUnidade 01: IntroduoUnidade 02: Start e Stop R/3Unidade 03: Configurao da CCMSUnidade 04: Administrao e Backup do Banco de DadosUnidade 05: BD: Procedimentos diriosUnidade 06: Processamento em BackgroundUnidade 07: Logstica de SoftwareUnidade 08: Autorizaes no R/3Unidade 09: Impresso e SpoolUnidade 10: Monitorao do SistemaUnidade 11: SAP Online Service System

Administrao e Backup do Banco de DadosContedo:Fundamentos de banco de dadosEstratgias de backupObjetivos:Agendar e executar backups FullAgendar e executar backups Transaction LogsVerificar os backupsVerificar a estrutura do banco de dado no discoReconhecer e resolver algumas situaes de erro

SQL: OverviewEstrutura: Datafiles Dados do Banco de Dados (*.mdf, *.ndf)Logfiles Transaction Log do Banco de Dados (*.ldf)

SQL: ConfiguraoEnterprise Manager Propriedades do Banco de Dados

SQL: ConfiguraoEnterprise Manager Propriedades do Banco de Dados

Oracle: Conveno de Nomes

Oracle: Estrutura dos Diretrios no R/3

Calendrio de Administrao do Banco de Dados

Importncia do Backup do Banco de Dados

Backups do Banco de Dadose dos Offline Redo Log file

Prevenindo e Localizando Erros

Backups Offline

Backups Online

Backup do Offline Redo Log File

Recomendao para Ciclo de Backup

Ferramentas de Backup do SAP

Questes de Implementao

Parmetros de Profile para Inicializao de Fitas

Inicializando um Conjunto de Fitas de Backup

Compresso de dados

Parmetros de Profile para Backup do Banco de Dados

Parmetros de Profile para Backup do Offline Redo Log Files

Schedulando um Backup

Monitoramento Dirio: Backups

Administrao BasisUnidade 01: IntroduoUnidade 02: Start e Stop R/3Unidade 03: Configurao da CCMSUnidade 04: Administrao e Backup do Banco de DadosUnidade 05: BD: Procedimentos diriosUnidade 06: Processamento em BackgroundUnidade 07: Logstica de SoftwareUnidade 08: Autorizaes no R/3Unidade 09: Impresso e SpoolUnidade 10: Monitorao do SistemaUnidade 11: SAP Online Service System

BD: Procedimentos diriosContedo:O Oracle Cost-Based OptimizerGerenciamento de espaoGerenciamento de TablespaceBackups do Banco de DadosMonitoresObjetivos:Monitorar o banco de dados OracleManter um banco de dados OracleMinimizar a indisponibilidade do sistema

Monitores de Banco de Dados: Overview

Oracle Cost-Based Optimizer

Estratgia de Duas Fases

Atualizando as Estatsticas do Oracle

Monitorando as Estatsticas do Oracle

Gerenciamento de Armazenamento

Checagem do Banco de Dados: sapdba -check

Monitorao Diria: Problemas com Extents

Monitorao Diria: Problemas com Espao Livre

Monitorao Diria: Backup

Monitorao Diria: Diretrio de Archive

Backup SQL DB13Transao DB13

Backup SQLO Backup do SQL sempre onlinePara que o Backup do SQL seja executado, necessrio que o servio de Agente do SQL esteja sempre ativo.

Backup do Banco - Windows

O Backup do Banco de Dados pode-se tambm serefetuado atravs do Sistema Operacional. Este backup dever ser OFFLINE.

Backup do Banco - WindowsTirar o Banco e SAP do arVerificar atravs da transao DB02 os arquivos que compe o Banco de Dados

Copiar os arquivos em mdia

Administrao BasisUnidade 01: IntroduoUnidade 02: Start e Stop R/3Unidade 03: Configurao da CCMSUnidade 04: Administrao e Backup do Banco de DadosUnidade 05: BD: Procedimentos diriosUnidade 06: Processamento em BackgroundUnidade 07: Logstica de SoftwareUnidade 08: Autorizaes no R/3Unidade 09: Impresso e SpoolUnidade 10: Monitorao do SistemaUnidade 11: SAP Online Service System

Processamento em BackgroundContedo:Overview do ambiente de processamento de background do R/3.Objetivos:Descrever as capacidades bsicas de processamento em background;Definir e schedular um job;Descrever os seguintes componentes:Programas ABAP, programas externos, comandos externos, eventos.Executar:Programas ABAP;Programas externos;Comandos externos.

Processamento em BackgroundObjetivos ( continuao ):Atribuir classes para os jobs ( prioridade );Monitorar jobs;Explanar sobre autorizaes para:Administradores do sistema;Usurios finais.Fazer uso da funcionalidade de processamento em background.

O que so Jobs em Background ?Jobs em background so:Coleo de um ou mais programas ABAP, programas externos ou comandos externos que rodam seqencialmente, sem interveno de usurios.Jobs em background podem:Processar tarefas automaticamente;Processar coleta de dados de sistema legados;Ser schedulados para rodar dinamicamente baseado em eventos ocorridosdentro e fora do R/3;Processar carga de dados sem afetar o processamento online.

Caractersticas de Processamento em Background (1)A schedulagem de jobs usa a funcionalidade de workload distribution a menos que seja atribudo para uma especfica instncia;Jobs em background so atribudos para classes A,B ou C;Background work processes podem ser reservados para jobs declasse A;Voc pode reservar um ou mais background work processes para executarjobs de classe A. Jobs atribudos para as classes B ou C nunca podem serschedulados para estes reservados work processes.

Caractersticas de Processamento em Background (2)A Job Scheduling Monitor no CCMS providencia uma visualizao grfica do ambiente de processamento em background.Os jobs podem ser schedulados e gerenciados usando:Programas ABAP baseados nos padres SAP para internal function modules ( Job API );SAP standard application usando a API ( Job API );Job Application Programming Interface (XBP-API) para comandos externos.

Schedulando e Processando

Jobs Selecionados para Execuo

Workload Balancing

Operation modes: Setup e Switching

Prioridades para Schedulagem

Configurando um Job em Background

Executando um Programa em Background

Definido um Novo Evento Usando a CCMS

Gatilho Internos de Eventos

Gatilhos Externos de Eventos

Executando Programas Baseados em Eventos

Adicionando Passos para Um Job em Background (1)

Adicionando Passos para Um Job em Background (2)

Reschedulando um Job de Background

Revendo o Log de Erros dos Jobs de Background

Revendo a Lista de Spool dos Jobs de Background

Monitorando Jobs: Overview

Monitores de Jobs Scheduling

Ferramentas para Administradores e Usurios Finais

Objetos de Autorizao para Jobs de Background

Objetos de Autorizao para Comandos Externos

Administrao BasisUnidade 01: IntroduoUnidade 02: Start e Stop R/3Unidade 03: Configurao da CCMSUnidade 04: Administrao e Backup do Banco de DadosUnidade 05: BD: Procedimentos diriosUnidade 06: Processamento em BackgroundUnidade 07: Logstica de softwareUnidade 08: Autorizaes no R/3Unidade 09: Impresso e SpoolUnidade 10: Monitorao do SistemaUnidade 11: SAP Online Service System

Logstica de SoftwareContedo:Transport Management System ( TMS )Cpia e transporte de clientsCustomizing Organizer e Workbench OrganizerObjetivos:Usar o TMS para administrar seu R/3, configurar sua rotasde transporte e importar change requestsExplanar sobre as caractersticas e limitaes das ferramentasdo R/3 para clientsUsar o Customizing Organizer e Workbench Organizer

Logsticas de Software em GeralA questo primria em logstica de software :Como voc obtm os direitos sobre os objetos no lugar certo e na hora certa ?A distribuio do desenvolvimento de software sempre requercoordenao, por exemplo, com o ABAP Workbench em vriossistemas R/3. Em alguns casos a questo :Como o cdigo fonte pode ser administrado ?Como as mudanas so feitas ?Como o desenvolvimento do projeto poder ser organizado ?

Estrutura de Dados no R/3

Tipos de Adaptao

Conseqncias: Logstica de Software no R/3

Sistema de Transporte (TMS): Conceitos

TMS: Administrando seu Sistema R/3

TMS: Configurando Rotas de Transporte

Opes de Mudanas no Sistema

Opes de Mudanas nos Clients

Resumo: Configurando o Sistema de Transporte1. Compartilhe o diretrio de transporte;2. Configure o controlador de domnio de transporte e defina o domnio;3. Configure o programa de transporte (tp);4. Na TMS: Inclua todos os sistemas no domnio;Defina as rotas de transporte.5. Configure as system change options de acordo com as regras para o sistema R/3;6. Crie clients e configure as system change options para o sistema de Produo,Desenvolvimento e assim por diante.

Transporte em um Single R/3 System

Cpia de Local de Client

Transporte Entre Sistemas: Fase de Setup

Remote Client Copy e Client Transport

Transporte Entre Sistemas: Fase de Manuteno

Gerenciando Change Request

Change Requests e Tasks

Customizao

Procedimento de Customizao

Procedimento de Workbench

TMS: Status do Buffer de Importao

TMS: Procedimento de Importao

Transporte Entre Diferentes Grupos de Transporte

AutorizaesAutorizaes para CO e WBOSuper usurio:S_CTS_ALLLder de projeto:S_CTS_PROJECDesenvolvedor:S_CTS_DEVELOUsurio final:S_CTS_SHOWTMSTMSADM:S_A.TMSADMTMSSUP:Autenticao quando loga no novo sistema R/3

Administrao BasisUnidade 01: IntroduoUnidade 02: Start e Stop R/3Unidade 03: Configurao da CCMSUnidade 04: Administrao e Backup do Banco de DadosUnidade 05: BD: Procedimentos diriosUnidade 06: Processamento em BackgroundUnidade 07: Logstica de SoftwareUnidade 08: Autorizaes no R/3Unidade 09: Impresso e SpoolUnidade 10: Monitorao do SistemaUnidade 11: SAP Online Service System

Autorizaes no R/3ContedoConceitos de autorizaes Profile GeneratorAdministrao de UsuriosObjetivo Descrever o modelo de autorizaes do R/3Mantendo autorizaesCriando usurio e atribuindo autorizaes

Usurios no Ambiente R/3

Conceitos de Autorizaes

Objetos de Autorizaes

rvore de Autorizaes de Usurios

Checagem de Autorizaes

Profile Generator: Overview (1)

Profile Generator: Overview (2)

Profile Generator: Overview (3)

Profile Generator: Etapas de Trabalho

Profile Generator: Criando Autorizaes

Dados Mestres de Usurios

Configuraes de Parmetros do Sistema para Profile

Segurana

Informaes do Sistema

Traces de Autorizaes

Administrao BasisUnidade 01: IntroduoUnidade 02: Start e Stop R/3Unidade 03: Configurao da CCMSUnidade 04: Administrao e Backup do Banco de DadosUnidade 05: BD: Procedimentos diriosUnidade 06: Processamento em BackgroundUnidade 07: Logstica de SoftwareUnidade 08: Autorizaes no R/3Unidade 09: Impresso e SpoolUnidade 10: Monitorao do SistemaUnidade 11: SAP Online Service System

Impresso e SpoolContedo:IntroduoOverview do spool do R/3Gerenciando impressorasDefinio de servidor de spoolGerenciando requisies de spoolAnlise de problemas de spoolAutorizaes para spool

Impresso e SpoolObjetivos:Descrever as funcionalidades do spool do R/3Definir output devices como local, remoto ou frontendDefinir um servidor de spool e usar com um output deviceTransportar output devices e suas definiesGerenciar spool e requisies de output Analisar e resolver problemas de impressoIdentificar autorizaes para spool

Introduo

Sistema de Spool

Spool e Requisies de Sada (Output Requests)

Banco de Dados TemSe

Spool Work Processes

Output Devices do R/3

Impresso Local no R/3

Impresso Remota no R/3

Administrao de Spool

Definindo uma Impressora Local

Definindo uma Impressora Remota

Impresso do Frontend no R/3.

Definindo um Impressora de Frontend

Servidor Lgico de Spool do R/3

Alternncia de Servidor de Spool

Definido um Servidor Lgico de Impresso

Transportando uma Arquitetura de Impresso

Gerenciando Requisies de Spool

Gerenciando Requisies de Spool

Lista das Requisies de Spool

Excluindo Requisies de Spool Antigas

Checagem de Consistncia do Banco de Dados de Spool

Anlise de Problemas de Spool

Autorizaes para Spool e Impresso (1)

Autorizaes para Spool e Impresso (2)

Administrao BasisUnidade 01: IntroduoUnidade 02: Start e Stop R/3Unidade 03: Configurao da CCMSUnidade 04: Administrao e Backup do Banco de DadosUnidade 05: DBA: Daily CheckUnidade 06: Processamento em BackgroundUnidade 07: Logstica de SoftwareUnidade 08: Autorizaes no R/3Unidade 09: Impresso e SpoolUnidade 10: Monitorao do SistemaUnidade 11: SAP Online Service System

Administrao BasisUnidade 01: IntroduoUnidade 02: Start e Stop R/3Unidade 03: Configurao da CCMSUnidade 04: Administrao e Backup do Banco de DadosUnidade 05: DBA: Daily CheckUnidade 06: Processamento em BackgroundUnidade 07: Logstica de SoftwareUnidade 08: Autorizaes no R/3Unidade 09: Impresso e SpoolUnidade 10: Monitorao do SistemaUnidade 11: SAP Online Service System

SAP Online Service SystemContedo:OSS: Overview / Funcionalidades / AcessoSAPNetObjetivos:Configurar a conexo OSSUsar as informaes e servios da OSS, SAPNete TechNet

OSS

OSS Overview

Overview

Funcionalidades OSS: Utilitrio de Pesquisa

Funcionalidades OSS:Problemas de Logging

Funcionalidades OSS: SSCR

Funcionalidades OSS: SSCR Overview

Funcionalidades OSS:SAP Hot Packages

Funcionalidades OSS:Informaes sobre Treinamento

Funcionalidades OSS:Informaes sobre Treinamento

Overview

Acesso a OSS

Acesso a OSS: Segurana de Rede - SAProuter

SAPNet

Homepage Pblica da SAP

SAPNet

SAPNet

SAPNet

SAPNet

SAPNet

SAPNet

SAPNet

SAPNet

SAP TechNet

**** Os clients do R/3 so organizados independentemente. Cada client tem seu prprio ambiente de dados, com dados mestres, dados de transaes, dados mestres de usurios e sua prpria customizao. Usurios em diferentes clients coexistentem no mesmo sistema R/3, mas seus dados so isolados e no podem ser acessados de outros clients. Somente usurios com as necessrias autorizaes podem visualizar ou processar dados em um client especfico. Esta concepo de isolamento refletida no projeto das tabelas do R/3. O client 000 definido como o standard do SAP no pode ser mudado pelo cliente. Este client serve como template para criao de outros clients. Um mximo de 997 clients podem ser criados pelo cliente.*************** Para inicializar o banco de dados Oracle e o R/3, o administrador R/3 executa os seguintes passos: Log no sistema operacional Windows NT como um usurio adm; Inicializa o banco de dados e o R/3 com o SAP Service Manager. Seleciona o sistema correto e d o START. O SAP Service Manager envia uma mensagem usando um named pipe para o servio SAP SAP_. O servio SAP inicializa o banco de dados executando um script NT chamando o Oracle Server Manager para rodar o script SQL o qual inicializa o banco de dados se ele no estiver rodando. Ento a central instance inicializada. O usurio adm pode agora inicializar application server adicionais e instncias. O sistema R/3 ter sido inicializado corretamente quando a luz verde acender no visor do SAP Service Manager.* Para inicializar o banco de dados Oracle e o R/3, o administrador R/3 executa os seguintes passos: Log no sistema operacional Windows NT como um usurio adm; Inicializa o banco de dados e o R/3 com o SAP Service Manager. Seleciona o sistema correto e d o START. O SAP Service Manager envia uma mensagem usando um named pipe para o servio SAP SAP_. O servio SAP inicializa o banco de dados executando um script NT chamando o Oracle Server Manager para rodar o script SQL o qual inicializa o banco de dados se ele no estiver rodando. Ento a central instance inicializada. O usurio adm pode agora inicializar application server adicionais e instncias. O sistema R/3 ter sido inicializado corretamente quando a luz verde acender no visor do SAP Service Manager.* Para inicializar o banco de dados Oracle e o R/3, o administrador R/3 executa os seguintes passos: Log no sistema operacional Windows NT como um usurio adm; Inicializa o banco de dados e o R/3 com o SAP Service Manager. Seleciona o sistema correto e d o START. O SAP Service Manager envia uma mensagem usando um named pipe para o servio SAP SAP_. O servio SAP inicializa o banco de dados executando um script NT chamando o Oracle Server Manager para rodar o script SQL o qual inicializa o banco de dados se ele no estiver rodando. Ento a central instance inicializada. O usurio adm pode agora inicializar application server adicionais e instncias. O sistema R/3 ter sido inicializado corretamente quando a luz verde acender no visor do SAP Service Manager.* Quando o usurio adm inicializa o SAP Service Manager, uma mensagem enviada usando um named pipe para o servio SAP. O SAP Service Manager pode rodar remotamente e conectar no servio SAP usando um named pipe e TCP/IP. Para descobrir quais os componentes que tem de ser inicializados, o SAP Service l a start profile do diretrio \\\sapmnt\\SYS\profile. Esta profile pode ser exibida com o SAP Service Manager. Se necessrio, o SAP Service inicializa o banco de dados; esto ele inicializa o message sever e o dispatcher. Para descobrir que tipos de work process podem ser inicializados, o dispatcher l a default profile e a instance profile e cria os work process e o gateway reader. Durante a inicializao, o work process conecta o ORACLE threads do banco de dados. Para exibir o log de inicializao, do SAP Service Manager, selecione View Trace. Voc pode tambm inicializar o banco de dados com o sapdba, com o Oracle Instance Manager, ou com o Oracle Server Manager. Voc pode tambm inicializar o sistema R/3 com o scheduler NT chamado at. Para este tipo de inicializao, o SAP providncia um executvel chamado STARTSAP e STOPSAP os quais so executados localmente. Veja tambm a documentao do R/3 Online no mdulo BC.* A ordem para providenciar um procedimento de inicializao estvel, a seqncia de leitura dos parmetros ( tambm conhecido como parameter replace sequence ), definida durante a fase de inicializao como segue: O processo R/3 l os parmetros do fonte C no kernel do R/3, das vaiveis de ambiente do NT, e do Registry do NT; A default profile \\SAPGLOBALHOST\sapmnt\\SYS\profile\defaul.pfl lida; os valores j definidos no fonte C so substitudo pelos valores da default profile; A instance profile \\SAPGLOBALHOST\sapmnt\\SYS\profile\__ lida; os valores j definidos no fonte C ou na default profile so substitudo pelos valores da instance profile. Este procedimento assegura que os parmetros do sistema reflitam no apenas a instance profile, mas tambm a default profile e o fonte C. Para exibir a seqncia de substituio para um parmetro em particular, execute o relatrio RSPFPAR na transao SE38 ou SA38. O SAP service l somente a start profile e a default profile. O kernel R/3 (disp+work.exe) l somente a default e instance profile. Assim, se voc mudar a default profile, voc deve reinicializar o SAP service ( incluindo a instncia R/3 ). Se voc somente mudar a instance profile, voc necessita reinicializar o R/3 com o SAP Service Manager.* Todos os eventos significativos, incluindo inicializao do banco de dados, paradas e erros, so gravados no Oracle alert file: \oracle\\saptrace\background\\ALRT.LOG. As informaes detalhadas de erros so registrados nos Oracle trace file: \oracle\\saptrace\usertrace\Ora.trc. Se o administrador usa o sapdba para inicializar o banco de dados, o sapdba grava arquivos de log adicionais nos seguintes diretrios de acordo com a atividade executada: :\oracle\\sapreorg; :\oracle\\sapcheck; :\oracle\\sapbackup.

* Todos as mensagens do Windows NT geradas pelos seus servios, pelo SAP Service Manager, ou pelo sistema operacional, so gravadas no NT Event Viewer. O Event Viewer escreve o EVENTLOG, o qual consiste de trs arquivos: System Log:Este contm as mensagens do sistema operacional e mensagens produzidas pelo R/3 ou aplicaes Oracle e retornadas pelo sistema operacional. Application Log:Este contm eventos que ocorrem, por exemplo, no R/3 e aplicaes Oracle e retornam destas aplicaes. Security Log:Este contm eventos como logon e logoff, acesso de arquivos por usurios, dependendo das propriedades de auditoria do sistema para o sistema de arquivos. O Event Viewer localizado no grupo Administrative Tools (Common) ou pode ser chamado com o prompt de comando usando o comando eventvwr.* Os diretrios do R/3 contm arquivos de trace e arquivos de erros de mensagens relativas a inicializao dos work process. Existe um diretrio de trabalho para cada instncia R/3. O diretrio de trabalho contm informaes as quais no podem ser encontradas no R/3 System Log. Os arquivos do diretrio de trabalho so inicializados em ordem cronolgica. Durante a inicializao, o SAP service executa o SAPNTSTARTB.EXE escrevendo: Logs do banco de dados no STDERR1; Logs do message server no STDERR2; Logs do dispatcher no STDERR3. Para definir o nvel de informao escrita nos arquivos de trace, configure o parmetro rdisp/TRACE na instance profile. Os valores para este parmetro so: 0 Escreve somente erros ( sem trace ); 1 Escreve mensagens de erros e warnings ( padro ); 2 Escreve mensagens de erros e short trace; 3 Escreve mensagens de erro e o trace completo. Voc pode tambm mudar o nvel de trace para um nico work process no Process Overview ( usando a SM50 ).* A indisponibilidade do R/3 pode ser planejada ou no planejada. A indisponibilidade planejada e schedulada para: Mudar os parmetros de profile; Executar um upgrade; Executar a manuteno do sistema operacional ou de hardware. As causas de uma indisponibilidade incluem problemas de hardware ( por exemplo, falha do disco ) e problemas de configurao.******************************* Os backups do banco de dados so realizados pela ferramenta da SAP BRBACKUP. Os backups do offline redo log file so realizados pela ferramenta da SAP BRARCHIVE. Existem 3 formas de chamar estas ferramentas: Usando o DBA Planning Calendar (DB13); Usando a ferramenta sapdba a nvel de sistema operacional; Diretamente do sistema operacional. A SAP recomenda os seguintes procedimentos: Schedular um backup com a DB13; Executar adicionalmente um backup com a ferramenta sapdba. Todas os passos do backup so registrados em arquivos do sistema operacional e em tabelas do banco de dados. Uma correta estratgia de backup deve contemplar: A disponibilidade do sistema ( 24x7, etc.) Hardware adequado; Treinamento dos envolvidos; Documentao do processo; Correto armazenamento; Plano de contingncia.** Antes de uma backup comear, voc deve inicializar as fitas que sero usadas. Isto significa que: Voc deve ajustar os parmetros de profile; Identificar as fitas. A profile init.sap usada para ajustar os seguintes parmetros: tape_use_count define com que freqncia a fita deve ser usada; expir_period define o tamanho do ciclo de backup. Para permitir que uma fita seja reutilizada depois de 28 dias, este valor deve ser ajustado para 28; backup_dev_type define o tipo dispositivo de backup vai ser usado. Para executar um backup em um dispositivo local de fita entre com tape. Outras opes incluem pipe, tape_auto, util_file e disk; volume_backup define um conjunto de fitas para o backup do banco de dados; volume_archive define um conjunto de fitas para o backup do offline redo log files. Os drives de fita so endereados usando a ferramenta MKS, que est disponvel no diretrio usr/sap//exe/run. O comando MT mapeia a conveno de nomes de drive Unix para de NT.* O procedimento de inicializao da fita deve ser executa como segue: Ajuste os parmetros volume_backup e volume_archive da init.sap. Neste exemplo: volume_backup = (.B01, .B02, .B03, .B04) volume_archive = (.A01, .A02, .A03, .A04)Para inicializar o conjunto de fitas, use o SAPDBAou BRPACKUP e BRARCHIVE com a opo -i force ( onde -i = inicialize e force ).Neste exemplo, as fitas .B01, .B02, .B03, .B04 e .A01, .A02, .A03, .A04 so inicializadas. Durante a inicializao, o label .tape.hdr0 gravado no primeiro arquivo de todas as fitas. Este label sempre lido e checado pelo BRBACKUP e BRARCHIVE. BRBACKUP e BRARCHIVE registra no label da fita usada os logs de backup e o banco de dados. Para sobrescrever os ajustes default, definidos no volume_backup e volume_archive, use o BRBACKUP e BRARCHIVE com a opo -v/volume. Dependendo da sua estratgia de backup, um nmero suficientes de fitas poder ser inicializado. O nmero de fitas depende do tamanho do banco de dados, do seu tipo de fita, do fator de compresso, do tamanho dos logs. Adicione 30% na necessidades de fitas.

* Use o parmetro init.sap para selecionar o modo de compresso. Se seu dispositivo de backup suporta compresso por hardware, ajuste o parmetro para hardware. Voc pode tambm especificar yes a compresso por software ou no . Use o SAPDBA para determinar o fator de compresso com o qual os seus dados sero backpeados. Este fator depende no nvel de preenchimento do seu banco de dados a ser backupeado. Devido a mudanas no nvel de preenchimento, voc deve determinar este nvel de compresso freqentemente ( pelo menos uma vez por ciclo de backup ).* Use a profile init.sap usada para ajustar parmetros para o BRBACKUP: Ajuste o parmetro backup_mode para all para executar um backup completo backup_type define se o backup online ou offline; tape_size define a capacidade da fita usada pelo BRBACKUP. Especifique o tamanho da menor fita do seu conjunto ( em MB ). Por exemplo, especifique 70000M para um tape de 70GB. O valor definido neste parmetro deve ser igual a capacidade no comprimida da fita. Quando os dados so backupeados seqencialmente para vrias fitas e somente um dispositivo de backup est disponvel, o BRBACKUP requisita as fitas na ordem definida pelo parmetro volume_backup. As fitas rebobinadas e no rebobinadas so requisitadas pelas ferramentas de backup da SAP. Um fita no rebobinadas deve ser nomeada com o parmetro tape_address, e uma no rebobinadas com o parmetro tape_address_rew.* Use a profile init.sap usada para ajustar parmetros para o BRARCHIVE: Ajuste o parmetro archive_function para -cds (copy_delete_save). Isto assegura que duas cpias de um offline redo log files so backupeadas para diferentes fitas.A opo -cds (copy_delete_save): Cria um segundo backup dos offline redo log files mais antigos existentes j backpeados uma vez; Apaga o offline redo log files que tenham sido backpeados duas vezes do diretrio de archive, em ordem de tamanho; Backupeia todos os novos offline redo log files pela primeira vez. O parmetro tape_size_arch define o tamanho da fita usado no BRARCHIVE. Especifique o tamanho da menor fita do seu conjunto ( em MB ). Por exemplo, especifique 50000M para um tape de 50GB. Os parmetros tape_address_arch e tape_address_rew_arch especifica os drives que dos dispositivos de backup que sero usados pelo BRARCHIVE. Se no forem definidos, o BRARCHIVE utiliza o parmetro tape_address e tape_address_rew para determinar o drive.* Use a transao DBA Planning Calendar ( DB13 ) para schedular um backup do banco de dados ( online e offline ) e do offline redo log file. Pelo menos uma vez por ciclo voc deve verificar seu backup. Para fazer uma verificao lgica e fsica do seu backup use a opo Verify. Os nomes das fitas a serem usadas para o backup so determinadas pelos parmetros volume_backup ( para o programa BRBACKUP ) e volume_archive ( BRARCHIVE ). Para modificar o nome default na caixa de dilogo Volumes to use. Para verificar o nmero e nomes das fitas requeridas para o backup, selecione Volumes needed na DB13 ou use o SAPDBA ( opo query only ). O nmero de fitas calculado de acordo com o tamanho do banco de dados, o parmetro tape_size e o fator de compresso. Os logs de backup so gravados nos diretrios sapbackup ( BRBACKUP ) e saparch ( BRARCHIVE ).* A transao Backup Log Monitor (DB12) exibe as seguintes informaes: O banco de dados e offline redo log file backupeados; Os arquivos de log gerados pelo BRBACKUP e BRARCHIVE; O ultimo backup bem sucedido; O ultimo backup mal sucedido; Todas as aes do backup; O estado do diretrio de archive; Como se backups do banco de dados e offline redo log file poderiam ser usados para um recovery. O DBA Planning Calendar (DB13) exibe o status de todas as atividades executadas.

*** Para aumentar a performance e minimizar a performance do sistema, o banco de dados Oracle deve ser monitorado diariamente. Para um overview dos indicadores de performance, o CCMS providncia os seguintes monitores: O Database System Check Monitor (DB16) exibe um overview de todas as principais funes e status do banco de dados; O Backup Log Monitor (DB12) exibe as informaes sobre o status do banco de dado e do backup do offline redo log file; O Tables and Indexes Monitor (DB02) exibe um overview do espao ocupado e status de outro objetos do banco de dados; O Database Performance Monitor (ST04) exibe um overview da carga de trabalho e configurao do banco de dados; O DBA Logging Monitor (DB14) providncia acesso ao logs de todas as aes de administrao do banco de dados, incluindo updates e otimizao de estatsticas. Cheque estes monitores diariamente para: O Cost-Based Optimizer no usar estatsticas obsoletas; Um grande nmero de extents esto sendo criadas; Problemas de espao.* O Cost-Based Optimizer usa um comando SQL para determinar a melhor estratgia para recuperar ou manipular informaes de uma banco de dados. A estratgia de acesso usada depende das informaes: Tabela consultada ( tabela, viso ou juno ); Campos especificados na clusula WHERE e comandos SQL; ndices definidos para a consulta da tabela. O Cost-Based Optimizer calcula o custo de de diversas estratgias para acesso as tabelas e seleciona a que requer a menor quantidade de dados acessados. Para calcular o custo da estratgia, o otimizador requer informaes estatsticas sobre as tabelas e ndices do banco de dados, como: Nmero de tabelas, ndices e nmero de blocos alocados por objeto; Nmero de valores distintos de cada coluna ou tabela. As informaes estatsticas para tabelas ou ndices so armazenadas no dicionrio do banco de dados. Para coletar estas informaes, use o comando SQL analyze table. Tabelas e ndices e a distribuio de valores podem mudar. Se o nmero de linhas de uma tabela difere grandemente dos valores da ltima vez que o analyze table rodou, a otimizao seleciona uma estratgia ineficiente e o tempo de acesso ao banco de dados poder ficar mais longo. Voc deve otimizar as estatsticas do banco de dados pelo menos uma vez por semana.* Somente a atualizao das estatsticas pode assegurar que o Oracle Cost-Based Optimizer selecione a melhor alternativa. Contudo, o processo de obteno das estatsticas e dispendioso e afeta negativamente o sistema. A SAP recomenda um estratgia de duas fases: Na primeira a fase, a ferramenta SAP determina quais tabelas requerem uma atualizao das estatsticas. O comando sapdba -checkopt PSAP% determina que objetos que contm estatsticas obsoletas, e modifica a tabela de controle DBSTATIC adequadamente. Na segunda fase, as estatsticas marcadas como TODO na tabela de controle DBTSTATIC so atualizadas usando o comando sapdba -analyze DBSTATCO.* Use o DBA Planning Calendar (DB13) para schedular as duas fases da estratgia para rodar consecutivamente. Check optimizer statistics determina quais os objetos requerem uma atualizao das estatsticas. Para determinar quais tabelas requerem uma atualizao das estatsticas selecione PSAP%: all SAP tablespaces. Atualize as estatsticas pelo menos uma vez por semana. Create new optimizer/space statistics atualiza a estatsticas das tabelas. Para atualizar todas as tabelas marcadas com a flag TODO, selecione DBSTATCO: all tables marked in DBSTATC.* Use os seguintes monitores para checar as estatsticas do banco de dados: Para exibir um overview das anlises por data, use o monitor Database Tables and Indexes Monitor (DB02), e selecione Checks Dates of table analysis. Para exibir informaes detalhadas sobre as estatsticas por tabela contida tabela de controle DBSTATC, selecione All tables; Para exibir os logs das aes do SAPDBA que so executadas para atualizar as estatsticas, use a DBA Logging Monitor (DB14) e selecione DB Optimizer; Para exibir o log de ao de check ou analyze do SAPDBA, selecione Functions IDs. Verifique os logs das aes executadas. Aes que no foram finalizadas com sucesso so marcadas em amarelo ( aviso ) ou vermelho ( erro) . Para exibir os detalhes do log SAPDBA, d um duplo click na ao do SAPDBA.

* Cada tabela e ndice so atribuas a um tablespace, que consiste de um ou mais arquivos de dados a nvel de sistema operacional. Todas as tabelas e ndices so armazenadas em arquivos de dados ( data files ) das tablespaces. O Oracle armazena tabelas e ndices em blocos individuais de 8K. Diversos blocos de dados de uma tabela ou ndice so agrupados para formar um extent. Os objetos de dados do Oracle possuem diversos parmetros que influenciam no crescimento. O primeiro extent ( initial extent ) dever ser grande o suficiente para as tabelas ou ndices esperados. Se um extent de um objeto de dado vir a falhar durante uma update ou insert, o Oracle tenta alocar um outro extent na tablespace Um objeto pode alocar extents at o limite de MaxExtents. O default para o valor de MaxExtents para O R/3 de 300. Se o nmero de extents por objeto alcanado, a mensagem de erro ORA-1631 ( para tabela ) e ORA 1632 ( para ndices ) exibida. Se isto ocorrer, voc deve aumentar o parmetro MaxExtents e checar o tamanho do prximo extent. Se no existe espao contnuo em uma tablespace para alocar um novo extent, a mensagem de erro do Oracle ORA-1653 ( para tabelas ) ou ORA-1654 ( para ndices ) exibida. As mensagens de erro do Oracle so armazenadas nos arquivos de log do Oracle e no R/3 System log (SM21).* Use o SAPDBA para checar o seguinte: Fragmentao de tabelas e ndices; Preenchimento de tabelas; Consistncia fsica do banco de dados, ou seja, a consistncia dos control file, redo log files e data files; Diversos erros e logs de alerta; Parmetros configurados no init.ora; Problemas especficos com o banco de dados e do ambiente R/3. Schedule o SAPDBA para rodar pelo menos uma vez por semana, usando a DB13 ou com o comando sapdba -check. O comando sapdba -check gera um arquivo de log chamado .chk, que gravado no diretrio sapcheck. As informaes de log tambm ~so escritas em tabelas do banco de dados, e podem ser visualizadas usando o Database System Check Monitor (DB16). Estas informaes de devem monitoradas depois de cada sapdba -check.* Para evitar problemas com tamanho de extent, o SAPDBA tem uma opo de ajuste automtico de extent ( -next ). Use o DB13 para schedular este ajuste para rodar uma vez por semana para as tablespace crticas que tem um alto crescimento de dados. Para rodar o SAPDBA para ajustar o extents, use o comando sapdba -next PSAP%. Os resultados do sapdba -next so gravados no diretrio sapcheck no arquivo .nxt e podem ser exibidos usando o DBA Logging Monitor com a funo ID nxt. Para ajustar o valor configurado para um nico objeto, use SAPDBA, e entre com d - Reorganization. O valor para o prximo extent dever ser de pelo menos 10% do tamanho do objeto. Para exibir a lista de tabelas e ndices que usam mas de 1 extent nas ltimas quatro semanas, use Tables and Indexes Monitor (DB02) e selecione Check Check next extent size. Olhe para os objetos que, como resultado de freqentes operaes de insert, tem alocado muitos extents ou se aproximado do MaxExtents. O Database System Check Monitor (DB16) exibe as informaes sobre os objetos que mais excedem o threshold ( default: 80 ) ou se aproxima do MaxExtents.* Use a Tables and Indexes Monitor (DB02) para: Analisar as tablespace que esto marcadas com problemas de espao; Cheque a taxa de preenchimento para determinar quando a tablespace alcanou um nvel crtico. Cheque a Database System Check Monitor (DB16) para problemas de espao. Problemas de espao so exibidos no log do comando sapdba -check. Estenda as tablespace com problemas de espao imediatamente. Para isto, use o comando c - Tablespace administration. Assegure-se que o tamanho do novo data file, no qual est localizada a extenso da tablespace grande o suficiente. Se necessrio voc pode adicionar um novo disco e criar um diretrio sapdata. Cheque o nmero mximo de data files permitidos em seu banco de dados. Este nmero definido no init.ora no parmetro DB_FILES. Nota: O limite MAXDATAFILES definido durante a instalao do banco de dados. Este limite s pode ser mudado com a recriao do control file do Oracle. Depois de mudar a estrutura dos data files, faa um backup do banco de dados, ou pelo menos dos novos data file e control file.* O Backup Log Monitor (DB12) exibe as informaes sobre: Os backups do banco de dados e offline redo log file; Os logs gerados pelo BRBACKUP e BRARCHIVE; O ultimo backup mal sucedido; O ultimo backup bem sucedido; As aes executadas pelo backup; O estado do diretrio de archive. Como seu backup do banco de dados e redo log file poderia ser usado para um recovery. A DBA Plannig Calendar (DB13) exibe o status de todas as atividades que foram executadas.* Se uma archive stuck ocorre: O banco de dados no consegue gravar o online redo log files; O banco de dados no executa nenhuma modificao nos dados; O SAPDBA no conecta com o banco de dados. Se o archive torna-se stuck, monitore os logs do banco de dados. O archive podem tornar-se stuck se: O banco de dados esta em modo archive, mas o Oracle archiver no est rodando. Se isto ocorrer, o SAPDBA exibe uma mensagem de erro. Use o SAPDBA para inicializar o Oracle archive. O diretrio de archive pode estourar, devido a grande quantidade de dados manipulados ( como um upgrade ou batch input ). Se isto ocorrer voc deve criar espao no diretrio de archive. Para criar espao no diretrio de archive, faa um backup do offline redo log files para uma fita, usando o SAPDBA ou o BRARCHIVE.*********** Processamento em background pode ser configurado em qualquer instncia R/3 usando o parmetro de instance profile rdisp/wp_no_btc. A combinao do nmero do job com seu nome faz com que ele seja nico no sistema Os jobs de background podem ser schedulados nas classes A, B ou C. O mnimo de dois dialog work processes so necessrios por instance,e estes so distribudos da seguinte forma: O background scheduler usa 1 dialog work processes para checar os jobs schedulados; O usurio necessita de 1 dialog work processes para trabalhos online. O sistema de transporte requer que, no mnimo, 2 background work processes devam estar disponveis.* Cada servidor com background work processes definidos tem seu background scheduler ativo. O background scheduler checa os jobs schedulados periodicamente. Para especificar o intervalo de tempo de checagem, ajuste o parmetro rdisp/btctime. O valor default de 60 segundos. O jobs podem ser schedulados como Immediate, Date/Time e Event-based. Se os jobs no podem ser Immediate ou Event-based por falta de recursos, eles so colocados na tabela de jobs como Date/Time. Depois da ativao, o background scheduler: Checa a tabela de jobs schedulados; Seleciona os jobs que ainda no tenham sido executados e o tempo de inicializao j tenha passado, ou os schedulados para incio imediato. Passa o controle para o Dispatcher que atribui um btc work process. * Para event-based, o message server checa as tabelas nos servidores para determinar quais os BTC work processes esto disponveis, e eles so randomicamente selecionados. Para time-based, o background scheduler checa a tabela de Job Scheduling periodicamente e faz uma requisio para o dispatcher para selecionar um BTC work processes disponvel. Jobs que tenham sido selecionados para execuo, mas que no podem rodar porque BTC work processes no esto disponveis, devem ser selecionados para rodar em um outro servidor quando o background scheduler inicializar. Nota: Se voc designar um servidor de destino, voc perde a vantagem do automatismo na distribuio do workload. Contudo, voc pode designar um servidor para fazer uso de um particular recurso.* Os operation modes so usados para alterar a distribuio de dialog e background work processes e para reservar background work processes para jobs classes A. Se um job est rodando quando h um processo de switched de operation modes, eles so marcados como pendentes e os jobs so completados.* Todos os jobs so priorizados em tempo de execuo. A tabela de job-scheduling neste exemplo mostra um job schedulado para s 8:00. O job scheduler usa o seguinte critrio de seleo: Jobs classes A com o servidor de destino; Jobs classes A sem o servidor de destino; Jobs classes B com o servidor de destino; Jobs classes B sem o servidor de destino; Jobs classes C com o servidor de destino; Jobs classes C sem o servidor de destino.* Para definir um job em background, execute os seguintes passos: Selecione Tools -> CCMS -> Jobs -> Define; Especifique o nome do Job e a classe do Job; Para enviar um requisio de spool para um usurio SAPOffice: Selecione Spool List Recipient; Entre com um dos seguintes campos do Recipient: Um usurio do SAPOffice; Uma lista de distribuio do SAPOffice; Um usurio do R/3; Um endereo de e-mail; Para salvar selecione copy. Todas as requisies de spool geradas por jobs so agora enviadas para este recipiente. Para especificar a prxima informao, selecione Step e salve a informao. Para especificar um informao de scheduling, selecione Start Date e ento salve.* Programas ABAP podem ser executados como background jobs . Contudo, se uma variante deve ser requerida se um relatrio tem uma seleo na tela. O R/3 inicializa um programa/comando externo inicializando o programa SAPXPG na mquina de destino atravs de uma Remote Function Call ( RFC). Programas/Comandos externos podem consistir, por exemplo, de um programa no R/3, comandos e scripts, que podem ser executados somente usurios com autorizao de background administration. Os programas ABAP so executados sincronamente, enquanto programas externos e comandos podem rodar sincronamente ou assincronamente, dependendo das necessidades. Todas as execues de jobs so gravadas no log de jobs.* Para definir um novo evento usando a CCMS, selecione Tools -> CCMS -> Jobs -> Define event. Novos eventos devem ser definidos ou como R/3 System event ou USER event. Eventos tpicos de R/3 so: SAP_END_OF_JOB; SAP_OPMODE_SWITCH; SAP_SYSTEM_START; SAP_SYSTEM_STOP; SAP_TRIGGER_RDDIMPDP. No use o R/3 System event para seus prprios programas, estes eventos podem ser mudados por futuras verses do R/3. No exemplo de USER event : END_OF_DATA_TRANSFER.* Para disparar ( trigger ) manualmente um evento interno de um sistema R/3, selecione Tools -> CCMS -> Jobs -> Raise event. Uma completa lista de todos os eventos que definidos no sistema R/3 so exibidos em uma tela pulldown. Voc pode selecionar um nome da lista ou digitar o nome do evento. Um parmetro opcional (ID) pode ser usado para distinguir um evento de outro. Depois de disparar um evento, qualquer job esperando um evento chamado END_OF_DATA_TRANSFER so schedulados agora para execuo. Voc pode tambm inicializar um evento usando um mdulo de funo BP_EVENT_RAISE. Para isto, selecione Tools -> ABAP Workbench -> Function builder.* Para disparar um evento externo do sistema, use no sistema operacional o programa sapevt. A sintaxe : \usr\sap\\SYS\exe\run\sapevent [-p ] [-t] [pf=] [name=] [nr = ], onde:= event name o nome definido na CCMS; = parmetro especificado ( opcional );-t = criao de trace ( opcional );< profile name> = caminho da profile ( opcional );< SID >= nome do sistema R/3 ( opcional ).= Nome da instance R/3 ( opcional ).

Exemplo: sapevt END_OF_DATA_TRANFER name=C11 nr=10

* Programas ABAP e programas externos podem evocar eventos os quais podem schedular jobs em background para execuo, dependendo destes eventos.* Para exibir a tela de Job Overview, use a transao SM37. Da tela principal, selecione Enter. Para adicionar um passo para um Job existente, siga os passos mostrados na tela. Voc pode somente mudar um Job que tem o status Scheduled ou Released. Jobs que esto rodando ou no podem ser mudados. Para mudar o status de um job que j tenha rodado, selecione Job Copy. Voc pode dar para o job um novo nome ou manter o mesmo. Agora o status Scheduled e o job pode ser modificado.* Quando os passos tenham sido adicionados e salvos, o job pode ser reschedulado para execuo. Lembre-se se salvar todas as mudanas nos jobs e as informaes de scheduling.* Para exibir a tela de Job Overview, use a transao SM37. Da tela principal, selecione Enter. Para reschedular um job que j tenha rodado, siga os passos mostrados nesta tela. Quando voc usa a funo Schedule Job, voc pode somente especificar a job scheduling information. Nenhum outra mudana no job pode ser executada aqui. Para reschedular um job que esteja com o status Released ou Scheduled, selecione: Job -> Change. Ento mude o critrio de schedulagem ou qualquer outra informao.* Para rever o log de erros dos jobs de background, acesse o Job Overview e selecione os seguintes passos mostrados na tela. Se exibir um erro no job, use a transao SM21 para rever o SAP System Log para maiores detalhes. * Para exibir a lista de spool, acesse a Job Overview, e siga os passos mostrados na tela. Para enviar uma lista de spool para a impressora, exiba a tela de Spool List e selecione Printer.* A informao exibida na tela de Job Overview depende da seleo que voc tenha feito na tela principal da SM37. Quando voc tem jobs schedulados esperando um evento, voc deve lembrar de selecionar o campo Or start after event na tela principal. Quando voc tem um job que tenha sido schedulado sem atribuir uma data de incio lembre-se de selecionar Jobs without start date na tela principal. Quando voc tem jobs que tenha sido schedulados baseados em um job anterior, voc deve lembrar de selecionar Jobs with previous job na tela principal.* Para acessar o Job Scheduling Monitor, use o seguintes caminho: Tools -> CCMS -> Control/Monitoring -> Job Schedul. Monitor. A coluna Job Server indica os nomes do servidores. Nomes duplicados indicam mltiplos work processes de BTC configurados por servidor. Se um nome de servidor no exibido, no existem operation modes definidos para este servidor. Se um operation mode tenha sido modificado para reservar processos de BTC para jobs de classe A, este tambm indicado na exibio. Cada retngulo exibido no Job Scheduler representa um job de background. Para encontrar informaes detalhadas sobre o job, selecione um retngulo. Para um explanao sobre todas as cores dos itens, selecione Legend.* Esta lista contm algumas das ferramentas que administradores e usurios finais podem usar para controlar o ambiente de background. Alguns administradores podem desejar restringir o uso destas ferramentas para seus usurios finais em seu ambiente ( recomendvel ).* S_BTCH_ADM: Para dar direitos de administradores entre com Y. O administrador pode acessar jobs em todos os clients. Sem esta autorizao, o usurio pode apenas trabalhar com o client onde esta logado. S_BTCH_NAM: Determina que usurios esto autorizados para schedular um job. S_BTCH_JOB: Determina as seguintes funes:

DELEExclui um job de usurio LISTExibe as requisies de spool criadas por jobs de usurios PROTExibe os logs criadas por jobs de usuriosRELELibera seu job automaticamente durante o schedulingSHOWExibe as definies de jobs de outros usurios.

* S_RZL_ADM: Esta autorizao requerida para permitir update e capacidades de manuteno para o administrador do sistema para o CCMS. Cdigo de atividade 01 permite o administrador todas as funcionalidades da CCMS. Cdigo de atividade 03 somente exibe a CCMS S_LOG_COM: Permiti executar comandos externos. Os seguintes campos esto disponveis:COMMAND:Nome lgico do comando externoOPSYSTEM:Nome do sistema operacional da mquina de destinoHOSTNome da mquina de destino ( HOST ) S_TCODE: Permiti executar as transaes SM49 ( Display/Execute ) e SM69 ( Define/Display/Execute )para comandos externos.

*** Como qualquer outro assunto relacionado com logstica, a logstica de software trata da distribuio de objetos no sistema R/3. No R/3, estes objetos podem incluir ajustes feitos durante a customizao, ou por softwares desenvolvidos internamente, feitos para serem usados com o R/3. Como softwares desenvolvidos internamente, estes devem necessitar ser transportados para diferentes sistemas R/3. O ambiente de desenvolvimento ABAP providencia ferramentas para ajudar o cliente a desenvolver software internamente. Usando estas ferramentas, diversos desenvolvedores podem trabalhar juntos em projetos envolvendo um nico ou diferentes sistemas R/3. Para projetos com desenvolvimento em larga escala, que so algumas vezes desenvolvidos simultaneamente em diferentes locais, a administrao de cdigo fonte um problema importante. Este problema no est limitado ao ambiente R/3, este um tpico assunto surgido durante qualquer projeto maior de desenvolvimento. Esta administrao de cdigo requer: Gravao das mudanas do cdigo fonte; Identificao do original e da cpia. Neste curso ns inicialmente estudaremos a estrutura do R/3. Em seguida ns discutiremos as solues para os problemas de logstica acima mencionados.

* O sistema R/3 consiste de vrios tipos de dados. Certos tipos de dados so somente acessveis de um client em particular. Como este tipo de dados inclu dados de aplicaes de negcios ( documentos, dados mestres de materiais e assim por diante), bem como cenrios de customizaes. Estes cenrios incluem: Definir a estrutura organizacional do cliente, como os canais de distribuio, cdigo das companhias e assim por diante; Ajustar os parmetros do R/3 para as especificaes de negcios do cliente Tipos de dados client-dependent so interdependentes. Assim quando um dados de aplicao imputado, o sistema checa se o dado esta coerente com a customizao. Se os dados de aplicao so inconsistentes eles so rejeitados. Contudo, os dados de aplicao normalmente so imputados em um ambiente de customizao especfico. Em adio aos dados client-dependent, o R/3 tem outros dados/ajustes que, uma vez definidos, so vlidos para todos os clients. Estes dados incluem: Customizaes client-independent , como configurao de impressoras; O repositrio R/3 que contm todos os objetos no dicionrio R/3 (tabelas, elementos de dados) bem como programas, menus, CUAs e assim por diante. Portanto, nos caso de configuraes client-independent, como um relatrio ABAP que foi desenvolvido inicialmente em um client pode ser usado imediatamente em qualquer client.* Em acordo com os diversos tipos de dados do R/3, existem vrios tipos de mudanas e ajustes de dados. Como o R/3 vendido de forma standard, ele deve ser ajustado para as requisies do cliente durante a fase de implementao. Este procedimento chamado customizao. Como mostrado acima, a customizao inclui os dados client-dependent e client-independent. Um upgrade do R/3 deve requerer um limitado nmero de customizaes. Diferente das customizaes, aperfeioamentos ou ajustes no repositrio do R/3 no obrigatrias para operar o sistema R/3. Para adaptar o repositrio do R/3 para uma requisio do cliente, desenvolvimento de softwares podem ser feitos. Em adio, customer enhancementes podem ser adicionados ao repositrio do R/3. Neste caso os objetos definidos pelos usurios so usados para complementar o standard vendido pela SAP. A precisa localizao onde estes enhancementes podem ser inseridos especificada pela SAP.Finalmente, objetos do R/3 como relatrios e definies de tabelas podem ser modificadas diretamente. Neste casos, diferente dos dois anteriores, o repositrio do R/3 no modificado. Durante a fase de upgrade estas modificaes devem ser ajustadas para o novo repositrio, que pode consumir tempo deste processo.* Devido as caractersticas do sistema R/3 descritas acima, o tipo e nmero de clients e sistemas R/3 so sujeitos ao seguintes requerimentos: A customizao no feita nos clients onde feito desenvolvimento e testes. Por esta razo, muitas implementaes requerem diversos clients. Para grandes instalaes, diferentes partes do projeto de customizao pode necessitar testadas juntas em clients separados. A produo vai requerer no final um client separado. No nvel tcnico, a distribuio destes clients ao longo de outros clients ( se possvel ) depende se alguma mudana ser feita no dicionrio. Se so necessrias mudanas, os ambientes de desenvolvimento e produo devem ser subdivididos e distribudos atravs de diferentes sistemas R/3. Contudo, programas ABAP que so criados em um client de desenvolvimento, mas ainda no testados, iro estar imediatamente disponveis para outros clients. Isto pode causar srios problemas de performance e segurana. Ento, para qualquer mudana feita no repositrio do R/3, a SAP recomenda pelo menos dois, melhor ainda trs, sistemas R/3. O terceiro sistema R/3 pode ser usado para massa de teste e medio de qualidade. Em resumo: Configuraes de customizao devem ser transportadas entre clients; Mudanas no repositrio do R/3 deve ser transportada entre sistema R/3.* O sistema de gerenciamento de transporte (TMS), que foi desenvolvido para a verso 4.0 do R/3, permite o transporte entre diferentes clients do sistema R/3 seja administrado centralizadamente. O TMS classifica o sistema R/3 grupos de transporte e domnios de transporte: Um grupo de transporte consiste de todos os sistemas R/3 que podem acessar um diretrio comum de transporte; Um domnio de transporte consiste de um conjunto de grupos de transporte.Assim, na verso 4.0B, system landscape consiste de diversos diretrios suportados. Para habilitar o transporte para ser administrado centralizadamente, todo os domnios de transporte devem ser capaz de administrados por um sistema R/3 designado, chamado controlador de domnio de transporte. Para administrar o transporte, as seguintes informaes so centralizadamente armazenadas: Os sistemas participantes do transporte; Sua rotas de transporte. Assim cada dado de configurao no necessita ser ajustado manualmente em todos os sistema R/3. Usando RFC, o controlador de domnio de transporte distribui os dados para todos os sistemas R/3 participantes.

* Para criar um domnio de transporte, defina o controlador de domnio quando voc chamar pela primeira vez o TMS no grupo de transporte. Assim que o domnio tinha sido criado, sistemas adicionais podem ser aceitos pelo domnio. Por razes de segurana, estes domnios no so aceitos at que eles tenham sido autorizados pelo controlados de domnio de transporte. O TMS System Overview exibe diversos status do sistema: Waiting for acceptance ( esperando por aceitao ); Active ( ativo ); System locked for the TMS ( sistema travado ); System not accepted ( sistema no aceito ); System deleted ( sistema excludo ). Tecnicamente, o TMS pode conectar sistemas com diferentes verses. Contudo, o R/3 no suporta qualquer transporte entre sistema de diferentes verses. Por ser de alta importncia, o sistema de controle de transporte dever rodar em um sistema R/3 de alta disponibilidade.* Para configurar as rotas de transporte entre sistemas no domnio, use o editor hierrquico e o edito grfico providenciado pelo TMS. Defina estas configuraes no sistema controlador de domnio. As rotas de transporte podem ser de consolidao (consolidation) e entrega (delivery). Para rotas de consolidao , uma camada de transporte ( transporte layer ) usada, por exemplo para definir um rota entre o desenvolvimento e o sistema de medio de qualidade. Rotas de entrega conecta sistemas, por exemplo o sistema de qualidade e sistema de produo. Ela no permite o uso de camadas de transporte. Para criar rotas de transporte no editor grfico, use drag & drop. Depois que a rota de transporte tenha sido configurada no controlador de domnio de transporte, ela pode ser distribuda atravs de todos os sistema do domnio. Nos sistemas ao longo do domnio, estas configuraes devem ser ativadas. Isto tambm pode ser feito centralizadamente pelo sistema de controle de domnio. Para habilitar configuraes anteriores para serem reutilizadas, voc pode criar verses no TMS.* No R/3 4.0 o conceito de faixas de nomes foi estendido para as faixas de nomes de programas desenvolvidos por clientes ( Y* e Z* ). Para habilitar objetos para serem modificados, o R/3 deve ser habilitado globalmente para mudanas (SE06). Para sistema de produo e qualidade os system change options (SE06) devem ser desabilitados e para sistema de desenvolvimento habilitados.* Freqentemente quando um sistema R/3 instalado, novos clients devem ser criados. A permisso para mudanas depende da funo do client. Por exemplo, nenhuma mudana permitida para um client usado em um sistema em produo. Para prevenir mudanas no client, o cliente pode impor restries de diversos nveis. Primeiro o cliente deve decidir se e como permitir configuraes client-dependent sejam mudadas. Feita esta deciso, o cliente deve distinguir clients os quais: Nenhuma mudana permitida; Mudanas so permitidas mas elas permanecem no client ( por exemplo para clients de treinamento ); Mudanas so permitidas e so permitidos transportes; Na maioria dos casos o cliente deve decidir se as mudanas devem ser gravadas automaticamente pelo Customizing Organizer ou somente ser transportadas manualmente. Em adio, o cliente deve decidir se permitir o repositrio do R/3 ou customizaes client-independent possam ser mudadas. Para clientes com dados de produo, medidas de segurana adicionais pode ser tomadas. No protection level, o cliente pode definir se permite um client ser sobrescrito por uma cpia de client ou se client pode ser acessvel externamente, por exemplo para comparaes de customizaes.** Depois que o sistema R/3 e seus clients tenham sido criados, estes sistema devem ser customizados e preenchidos com dados. O primeiro passo para configurar um sistema R/3 para um cliente consiste no processo de customizao. A customizao feita em um client separado. Esta customizaes podem ser distribudas atravs de outros clients e em outros sistema s R/3. Durante este processo importante diferenciar entre: Target client ( client de destino ) com dados que devem ser mantidos; Empty Target client que no foram preenchidos com dados. Para Target client com dados existentes, transporte as customizaes usando a SCC1. Esta transao permite que entradas simples possam ser transportadas sem deletar o Target client completamente. Para Empty Target client que necessitem de uma nova configurao, os customizaes devem ser transportadas usando a cpia local de client. Uma cpia local de client pode transportar todas as customizaes e tambm os dados de aplicao. Devido a dependncia de dados, o target client normalmente excludo antes dos dados serem copiados. Ento, uma cpia local de client no pode misturar dados de diferentes clients. Estas so as razes para o client de destino estar vazio.* A cpia local de client distribui os objetos client-dependent entre clients pertencentes a um sistema R/3. Estes objetos incluem dados de customizao, dados de aplicao, dados mestres de usurios e autorizaes. Aqui, novamente, dados de aplicao somente fazem sentido no ambiente especfico de customizao. Por esta razo, o R/3 no permite copiar dados de aplicao sem copiar simultaneamente dados de customizao. Contudo, cpias separadas de usurios e dados de customizao so permitidas. Para dados de customizao, qualquer dados existente no client de destino normalmente excludo antes dos dados de customizao serem copiados. Depois dos dados a serem copiados tenham sido selecionados, eles so transportados por relatrio ABAP o qual procura em todas as tabelas a serem copiadas para entradas pertencentes ao client de destino. Para assegurar a consistncia durante a fase de cpia, o R/3 previne os usurios a no se logarem no client de destino; Como a cpia de client envolve um grande escala de dados transportados no banco de dados, a cpia de client dever somente ser inicializada como um job de background.* O prximo passo o transporte entre diferentes sistemas R/3 e domnios de transporte. Durante este transporte voc deve diferenciar entre as fases: Fase de setup: Onde existem dados no relevantes como client-dependent no destino e a subsequente fase. Fase de manuteno: Onde um completo conjunto de dados existe no destino R/3. Para a fase de setup, o R/3 providncia as seguintes ferramentas: O Workbench Organizer e o sistema de transporte; Remote client copy e client transport. Durante a fase de setup, o repositrio do R/3 deve ser primeiro replicado. Desenvolvimentos de software, como programas ABAP devem ser transportados para o novo sistema R/3, usando change requests, as quais so executadas pelo Workbench Organizer e o sistema de transporte. Em seguida, as customizaes so transportadas para o novo sistema. A ferramentas de remote client copy e client transport so usadas para transportar os dados de customizao. Client transport e change requests usam o diretrio de transporte alcanar o sistema de destino. Remote client copy transporta dados usando um conexo RFC. Remote client copy e client transport no so desenhadas para transferir dados em larga escala ou migrao de dados.* Normalmente ambos, remote client copy e cliente transport trabalham com os mesmos dados como um cpia de client local, isto , com customizaes, aplicaes e dados de usurios. Assim aplicasse as mesmas restries j mencionadas. Em adio, client transport e remote client copy so tambm usadas para transferir dados customizaes client-independent. O procedimento de remote client copy inteiramente anlogo ao cpia de client local, e ambos os casos um relatrio ABAP processado. Porm, a cpia local escreve dados para uma mesma tabela ( somente a muda a chave client ), durante um remote copy, os dados so transferidos usando um RFC, isto , uma conexo de rede. O client transport l os dados das tabelas e escreve para o diretrio de transporte. Dependendo do client o arquivo resultante pode crescer para diversos GB. Um pr-requisito para o uso de ambas as ferramentas que o repositrio da sistema de origem e destino sejam idnticos. Se existir qualquer diferena os dados no so copiados corretamente. Finalmente, um client transport importado usando o TMS. Uma separada transao R/3 requerida para o ps-processamento.* Assim que os dados tenham sido copiados para o sistema R/3, o remote client copy e o client transport j no podem ser usados para transportar mudanas para customizao. Ento, mais adiante as mudanas so distribudas usando o Customizing Organizer. Para usar o CO, voc deve primeiro ativar a gerao automtica de requests para o client. Assim como o Workbench Organizer (WBO), o CO grava os objetos que tenham sido modificados. Neste caso de customizaes, estes dados so basicamente configuraes em tabelas. Durante a fase de manuteno, as mudanas no repositrio do R/3 e os dados client-independent continuam sendo transportados usando o WBO. Assim a principal diferena entre as duas ferramentas que o CO usado basicamente para gerenciar as mudanas de customizao. Ento, o CO pode ser usado tambm para gerenciar Workbench requests. Para manter Customizing e Workbench development separados logicamente, as mudanas no repositrio do R/3 devem ser gerenciadas usando somente o WBO. Ambos, customizing e WBO permitem gravar objetos para ser transportados para o diretrio de transporte local. Do diretrio de transporte os dados so importados para o sistema de destino, usando o sistema de transporte.* A estrutura lgica do WBO e do CO muito similar. Ambas ferramentas so desenhadas para gravar e transportar change requests, e elas suportam a coordenao de projetos de customizao e desenvolvimento de uma equipe. Novamente, as diferenas entre estas duas ferramentas so somente devido a serem usadas para gravar e gerenciar diferentes objetos. Objetos do repositrio como programas ABAP, definies de tabelas e assim por diante, tem estrutura bem definida. Entradas de tabelas que tenham sido feitas durante a customizao no tem esta estrutura. Ento, o gerenciamento de verso e as opes de travamento e a atribuio de classes de desenvolvimento podem somente ser feitas para objetos do repositrio que so gerenciados pelo WBO. Para obter um histria das mudanas feitas pela customizao, voc deve ativar a tabela de log. Para ativar a tabela de log, use o parmetro de profile rec/client e a tabela de histria no menu de customizao. Nota: A simples documentao de TODAS as requests geradas para customizao e seu propsito a MELHOR ferramenta para mapear todo o processo de parametrizao do sistema.* O WBO e o CO permitem voc trabalhar com um equipe de projeto de desenvolvimento e customizao, e permite que as mudanas feitas no R/3 sejam gravadas. Estas mudanas so gravadas usando change requests que so criadas ao longo de todo projeto. Esta requests contm pequenas unidades consistidas de tarefas (tasks) que tenham sido desenvolvidas por um membro do projeto, ou seja, a lista de todas as mudanas feitas nos objetos. Em geral, um objeto pode ser listado em diversas tasks pertencendo a uma mesma change request ( com exceo de reparao ). Igualmente, um membro do projeto pode ter suas diversas tasks pertencendo e uma change request. Os objetos gravados so somente transportveis no contexto de toda a change request. Assim projeto representado nesta change request pode somente ser transportado por inteiro para outro sistema R/3. O SAP Software Change Registration (SSCR): Antes de objetos serem processado no Workbench, todo o desenvolvedor deve estar registrado na OSS. Quando objetos SAP so modificados, uma chave para o objeto tambm deve ser requisitada junto a OSS.* Quando o sistema R/3 implementado, a customizao de central importncia. A SAP entrega o standard que deve ser adaptado para os requerimentos da companhia. Para este propsito, a SAP entrega o Reference Implementation Guide (IMG). Este guia de implementao contm as customizaes para todos os mdulos disponveis. Em geral, quando o sistema R/3 instalado, somente certos mdulos so mudados pelo cliente, por exemplo FI e CO ( Nota: Este fato no se aplica para a realidade brasileira ). As aes requeridas para customizao so resumidas no Enterprise IMG, o qual deve ser gerado no incio da customizao. Porm, at mesmo o Enterprise IMG contm muitas transaes de customizao. Ento o Enterprise IMG dividido em Projects IMGs, que podem ser usado por uma equipe de implementao. Ambos, Enterprise IMG e Projects IMGs so client-independent. As mudanas feitas nas transaes de customizao que so sumarizadas no Project IMG podem ser gravadas em change requests.* Quando uma transao de customizao executada e as modificaes salvas, as modificaes so gravadas no Customizing Organizer. Estas mudanas so atribudas a change request. Esta request j pode existir (isto , ela no foi ainda liberada), ou criada pelo usurio. Na request as mudanas so salvas nas respectivas tasks do usurio. Quando uma task liberada, uma documentao pode ser criada para descrever o tipo de mudana e a razo para isto. Depois que todas as tasks pertencentes a uma request tenham sido liberadas, a change request pode ser liberada. Normalmente, com a liberao, os objetos so exportados para o diretrio de transporte. Durante o export e durante a concluso do import para o sistema de destino (usando a TMS), faz sentido checar o transporte. O sistema de transporte relata erros usando return codes. Um return code 0 significa um transporte sem erros; 4 um warning; e 8 ou superior um erro. Um erro sempre requer um ps-processamento.* Objetos individuais do repositrio do R/3, como relatrios ABAP so desenvolvidos em um processo similar ao de customizao. O Workbench Development somente diferente do Customizing porque diferentes tipo de objetos esto envolvidos. Um novo desenvolvimento comea quando um objeto criado, por exemplo no editor ABAP ou no dicionrio R/3. Este objetos devem primeiro ser atribudos a uma classe (Nota: Jamais usar a classe $TMP , porque estes objetos no podem ser transportados). Desta forma, os objetos so logicamente distribudos em um projeto, por exemplo, desenvolvimentos de HR; em adio os atributos de transporte so definidos. O dado ento gravado, como na Customizing Organizer, na forma de tasks. Porm, quando repartidos com o repositrio de objetos, este objetos so bloqueados para o acesso de membros no pertencentes a request. Desta forma, o projeto esta claramente definido. Depois de todas as tasks pertencentes a request tenham sido liberadas, a change request esta liberada. Quando a requisio tiver sido liberada, os objetos so exportados, verses so criadas e os bloqueios excludos. Os objetos esto livres para novos projetos. Se as mudanas nos objetos do repositrio do R/3 no envolve novos desenvolvimentos de software, mas consiste somente de mudanas de relatrios existentes, uma classe no precisa ser atribuda. Porm voc deve distinguir os objetos existentes como originais, e fazer cpias destes objetos originais.* O ltimo passo no transporte das modificaes de Customizing e objetos de Workbench entre diferentes sistemas R/3 a importao do diretrio de transporte para o sistema R/3 de destino. O TMS faz esta importao. A mais importante estrutura organizacional para o gerenciamento de importaes para um sistema o especfico buffer do sistema, no diretrio de transporte. Neste buffer, as change requests so importadas de um conjunto de ordens que precisam ser liberadas. Assim, o buffer implementa a importao da fila. Usando o TMS, voc pode exibir a fila de importao de todos os sistemas R/3 de um domnio de transporte. Para todas as filas de importao, o nmero de change request, bem como o status da fila exibido. Os status pode ser o seguinte: Open: Isto , novas change requests podem ser adicionadas e importadas durante a prxima importao; Closed: Isto , novas change requests no so importadas durante o prximo full import da fila.Se a fila contm erros ou se est rodando a importao, ela no pode ser lida. A exibio dos dados da fila de importao no atualizada automaticamente pelo TMS.* Depois que voc selecionou um sistema, o TMS exibe os detalhes da fila de importao selecionada. Se as requests tem origem no mesmo domnio, estes detalhes incluem: A ordem e o nome da requests; O proprietrio da request acompanhado de um texto; A lista de objetos, documentao, e log de transporte. Usando o TMS, request em qualquer fila de importao pode ser transportada de qualquer sistema no domnio de transporte para um sistema de destino selecionado. Existe uma importante diferena entre importar todas as requests de uma fila, e o importao preliminar de uma simples request. Devido a interdependncia dos dados do sistema R/3, a SAP recomenda sempre trabalhar somente com um importao completa ( Nota: Apesar desta recomendao, este procedimento oneroso, perigoso e dificilmente utilizado ! ). Portanto a importao de toda a fila e a opo padro no TMS. Uma simples request pode ser importada usando a TMS. Porm, neste caso, o importador deve estar seguro que no existem inconsistncias, por exemplo, um objeto requerido que esteja faltando. Assim, por exemplo, um relatrio ABAP que importado sem a referida tabela, poder gerar short dump no sistema de destino. Em adio, o TMS permite voc monitorar o procedimento de transporte usando um monitor. Para outras anlises, voc pode usar vrios logs de transporte a nvel de sistema operacional.* O TMS incorpora diferentes grupos de transporte para um mesmo domnio de transporte. Esta incorporao permite o transporte entre sistemas R/3 pertencentes a diferentes grupos de transporte em diferentes domnios de transporte. Transporte entre sistemas R/3 para diferentes grupos de transporte requer uma transferncia dos dados da requisio de transporte para diferentes diretrios de transporte. Antes que transporte de request possa ser feito, a fila de importao do sistema de destino deve ser ajustada. Para fazer este ajuste, o sistema procura pela request em para o sistema selecionado em todo o grupo de transporte. Se a request for encontrada, ela exibida para transferncia. O TMS tambm copia os arquivos associados ( data e cofiles ) de um especfico diretrio de transporte para o diretrio de transporte que est conectado com o sistema de destino. Os logs de transporte no so transportados para diferentes grupos de transporte. Para exibir o log de transporte, por exemplo, para uma importao de um grupo de transporte de um sistema R/3, voc deve usar o TMS deste grupo de transporte.* As autorizaes para o WBO e CO so divididas nas seguintes categorias: Super usurio: Tem todas as autorizaes relacionadas com requests e tasks. Lder de projeto: Pode criar e gerenciar requests e tasks. Desenvolvedor: Pode usar somente requests existentes. Usurio final: Somente tem autorizao para exibio. O objeto bsico de autorizao S_TRANSPRT. Como fazer a comunicao entre diferentes sistemas R/3 ? A tcnica bsica uma conexo RFC gerada pelo TMS. O usurio padro pelo qual a conexo estabelecida o TMSADM. Este usurio somente exibe as autorizaes. Assim que um autorizao mais completa requerida, a conexo e estabelecida atravs do usurio TMSSUP. Este usurio no tem senha no R/3, e deve ser ento novamente autenticado para todos os sistemas de destino. Desta forma, as autorizaes so estabelecidas.*** Existem diversos usurios fora do sistema R/3, como usurios do sistema operacional, usurio do banco de dados e administradores. Esta unidade foca os usurios do R/3 no sistema R/3. O usurio R/3 conhecido apenas dentro do R/3 e no pode ser logar no sistema operacional e banco de dados. Ento, antes de acessar o R/3 como usurio final, voc deve primeiro logar no sistema operacional. Para acessar o dados e funes do R/3, o usurio deve ter apropriadas autorizaes. Por exemplo, um usurio R/3 responsvel por manter dados mestres de usurios tem a autorizao para executar a tarefa nesta rea, mas no autorizado, por exemplo, para acessar documentos de SD.* As autorizaes asseguram acesso limitado a transaes e objetos do R/3 que necessitam de proteo, por exemplo, o cdigo da companhia e do vendedor. Autorizaes so atribudas nos dados mestres dos usurios nas profiles.Para cada atividade ou transao, uma autorizao checada para ver se a referida autorizao foi atribuda ao usurio. O R/3 permite atribuir autorizaes a nvel de transao. Se um usurio tem a requerida autorizao, outras checagens so realizadas durante a transao para ver se o usurio tem acesso a dados protegidos como cdigo da companhia. * As autorizaes sempre pertencem ao objeto de autorizao para o qual ela foi criada. Os objetos de autorizao so agrupados em classes de objetos, que so organizados por reas de negcio. O objeto de autorizao usado como um modelo para manuteno e para as checagens de autorizaes nos programas. Para criar ou mudar uma autorizao, voc deve entrar com certos valores nos campos do objeto de autorizao. Neste exemplo, os valores Display e Change so preenchidos no campo do objeto Activity para a autorizao A. A autorizao B contm somente Display. Dentro das autorizaes e relatrios, os objetos de autorizao so checados. A combinao de campos checados so especificadas no objeto de autorizao.* A rvore de autorizaes do usurio mostrada aqui indica como as autorizaes so atribudas nos dados mestres dos usurios. O dado mestre do usurio pode conter uma ou mais profiles, que so resultado dos grupos de atividades atribudos. As profiles compostas contm uma coleo de profiles simples ou compostas. Ao usurio atribuda todas as autorizaes de todas as profiles atribudas nos dados mestres. As profiles podem ser criadas ou modificadas usando um dos seguintes mtodos: Usando o Profile Generator; Manualmente ( verses anteriores ).* Todas as autorizaes que tenham sido atribudas para os usurios nos dados mestres so armazenadas no buffer do usurio no momento do logon. Antes das transaes ou relatrios serem executados, a combinao de campos dentro dos objetos de autorizao so comparados com as autorizaes do buffer do usurio. Se uma autorizao para um particular objeto de autorizao contm a requerida combinao de campos e valores, o acesso permitido e o processamento continua. Se no existe a autorizao requerida, uma mensagem de acesso negado enviada.* O Profile Generator simplifica a atribuio das autorizaes para os usurios pela seleo do menu de transaes da companhia, e agrupando estas transaes em grupos de atividades. O grupo de atividade gerado desta forma atribudo a um ou mais usurios. O usurio pode ser atribudo a um ou mais grupos de atividades.* Uma vez que as transaes tenham sido atribudas a um grupo de atividade, o Profile Generator automaticamente identifica os objetos de autorizao que necessitam ser checados para este grupo particular de transaes. Os valores que precisam ser checados so providos pelo sistema. Quando usamos o Profile Generator, o administrador deve executar as seguintes atividades: Checar as autorizaes propostas pelo sistema; Fornecer os campos que no foram fornecidos pelo sistema; Gerar profiles de autorizaes para os grupos de atividades. As autorizaes necessrias para estes profiles so criadas e geradas pelo Profile Generator. Atribuir para os usurios os profiles.* O Profile Generator permite gerar grupos de atividades com responsabilidades. Transaes atribudas para este tipo de grupo de atividades so vlidas para todas as responsabilidades includas no grupo. Usando responsabilidades, a mesma descrio funcional pode ser atribudas para diferentes nveis organizacionais. As profiles e usurios so atribudos para uma particular responsabilidade e no para o grupo de atividade.* Para acessar o Profile Generator, selecione Tools -> Administration -> User Maintenance -> Activity groups, ou rode a transao PFCG. Especifique as atividades para o grupo de atividades: No menu da companhia, selecione todas as transaes necessrias. O farol ficar verde se todas as transaes forem selecionadas, amarelo para algumas ou vermelho para nenhuma. Quando usamos grupo de atividades com responsabilidades, voc deve definir as responsabilidades para serem includas no grupos. Neste caso, os seguintes passos devem ser executados para cada responsabilidade: Criar um authorization profile ( perfil de autorizao ): Mantenha os nveis organizacionais e todas as autorizaes sem valores do sistema. Quando for checar as autorizaes que devem ser atribudos valores. Use o Profile Generator para gerar as autorizaes e os profiles do grupo de atividade. Para entrar com o profile de um grupo de atividade ou responsabilidade nos dados mestres do usurio de um ou mais usurios, use as seguintes funes no Profile Generator: Assing users: Esta funo atribui usurios para o grupo de atividades ou responsabilidade. O perfil de autorizao no contudo atribudo no dados mestre do usurio. User master record update: O perfil de autorizao do grupo de atividade ou responsabilidade preenchido no dado mestre do usurio.* Uma vez que as transaes tenham sido atribudas no grupo de atividade, o Profile Generator exibe todas os objetos de autorizao checados para estas transaes. A exibio dividida em trs nveis: O primeiro nvel contm as classes de objetos, como financeiro (FI); O segundo nvel contm objetos de autorizao como: Customer: Authorizations for company codes F_KNAI_BUK; O terceiro nvel contm autorizaes como: Customer: Authorizations for company codes T_500... Para cada autorizao, campos e valores so exibidos, por exemplo, Activity 02. Cheque as autorizaes geradas pelo Profile Generator. Ento de manuteno nas unidades organizacionais, como cdigo da companhia, para cada grupo de atividade com uma funo central ( selecionando Org. levels ). Para dar manuteno em autorizaes que no tem entradas geradas pelo Profile Generator, click no lpis vermelho prximo a estes campos. Para encontrar a documentao, d um duplo click no objeto de autorizao no segundo nvel. A luz do farol indica o status da autorizao: Verde: Todas as autorizaes foram ajustadas; Amarela: Algumas autorizaes foram ajustadas; Vermelha: Nenhuma autorizao foi ajustada. Para exibir os nomes tcnicos e cones, use o item de menu Utilities -> Technical names on.* Para atribuir os valores padres para uma impressora, requisies de spool, menu do usurio, formato de data ou linguagem, selecione Defaults. Para definir um endereo de negcio para sua documentao use a opo Address. Para ajustar o valor padro dos campos do R/3 para um usurio, entre com os valores na opo Parameters. Para mudar a senha do usurio, use a opo Change Password. Os usurios podem manter saus prprias configuraes selecionando System -> User Profile -> Own data.* Para configurar o R/3 para reconhecer os requerimentos mostrados aqui, parmetros de profile do sistema que comeam com login/. Depois de vria tentativas de logon, negado o acesso ao usurio ao sistema. Este limite do nmero de falhas ajustado no parmetro de profile: login/fails_to_user_lock. Toda a meia-noite todos os usurios que estiverem locados devidos a logon incorreto sero desbloqueados. Para prevenir o unlocked automtico, ajuste o seguinte parmetro de profile: login/failed_user_auto_unlock ( Veja a nota 66533 ). Para acessar a lista de usurios locados ou exibir os usurios com logon incorretos, use a transao SUIM. Quando mudar sua senha, observe os seguintes pontos: Sua senha deve ser diferente das ltimas cinco senhas usadas; No comece a senha com qualquer seqncia de caracteres de trs letras contidas no nome do usurio; No use pass ou sap como sua senha; No comece com trs caracteres idnticos; No comece com sinais de exclamao (!) ou interrogao (?).* Clients 000, 001 e 066 so parte do sistema R/3 entregue. Nos clients 000 e 001 existem dois usurios especiais: SAP* para acesso inicial ao R/3; DDIC para o transporte e correo do sistema. Para proteger o SAP* e o DDIC de um acesso desautorizado, voc deve mudar a senha inicial destes usurios em todos os clients do seu R/3. A SAP recomenda adicionar o grupo SUPER para os dados mestres dos usurios. Este grupo pode somente ser acessado por um super-usurio. O client 066 o client de EarlyWatch. Os clientes devem mudar a senha inicial de seus prprios sistemas. Em todos os clients existe um usurio chamado SAP* com a senha pass o qual tem todas as autorizaes. Este usurio pode ser usado se nenhum outro usurio existir no client. Por razes de segurana, o usurio SAP* deve existir em todos os clients. Para desativar o SAP*, use o parmetro de profile do sistema: login/no_automatic_user_sapstar ( Veja a nota 68048 ).* As informaes do sistema permitem voc acessar os registros do usurio e profiles baseada nos objetos de autorizao que ele contm. O sistema de informao tambm lhe proporciona uma histria de mudanas de senhas, tipo de usurio, grupo de usurio e mudanas nas autorizaes. Para acessar as informaes do sistema, use a transao SUIM.* O R/3 permite encontrar quais objetos de autorizao so checados quando voc roda um programa. Para gravar as checagens de autorizaes, use o trace do sistema. Para inicializar o trace do sistema,