TADM12 - PARTE 2 / 2

Unit 1 - Introduction to SAP Software Logistics SAP System Landscape

O ICM é a interface para a internet. Ele pode trabalhar com requisições Web como server e client; Suporta vários

protocolos (HTTP, HTTPS e SMTP). O SAP NW AS pode ser usado como um Web Server e como um Web Client;

O ABAP-Dispatcher despacha requisições para os WPs. Se todos WPs estiverem ocupados, a requisição é colocada na fila do Dispatcher-Queue;

O ABAP WP executa o código ABAP; O MS (Message Server) faz o intercâmbio das mensagens e pode executar o

Load Balancing no sistema SAP; Na parte JAVA do SAP NW AS existem componentes como Java-Dispatcher ,

Server Process, SDM - (Software Deployment Manager) e a SCS Central Services; O SAP JCO (SAP Java Conector) provê comunicação entre o ABAP-Stack e o

Java-Stack do SAP NW AS nas duas direções. Requisições de clientes para o SAP NetWeaver AS Java são manipulados pelo Java-Dispatcher. Ele seleciona um Server Process livre para servir a requisição realiza uma conexão entre o client e o Server Process. O Java-Dispatcher trabalha de acordo com o algoritmo “Round Robin”. O SDM - (Software Deployment Manager) é a ferramenta padrão com que os componentes J2EE são instalados no SAP NW AS Java. A SCS-Central Services é executado em um Server e forma suas próprias Java Instances. A SCS consiste de um Message Server e um Enqueue Service e são a base para comunicação e sincronização para o Java Cluster.

Cada instance do SAP NW AS ABAP+Java contém o ABAP Dispatcher com seus WPs e o Java Dispatcher com seus Servers Process. Uma das instances é habitualmente instalada como um ABAP Central Instance, o que significa que os WPs executam aqui. Alternativamente o sistema pode ser instalado sem uma Central Instance, mas com um Enqueue Server stand alone (autônomo). As aplicações e dados para ABAP e Java possuem seus próprios schemas em um mesmo DB. Usuários podem se conectar e comunicar com o sistema SAP usando SAPGUI ou um Web client (browser). Comunicação usando o SAP GUI: usuário conecta usando o Message Server (para load balancing) ou diretamente para um ABAP Dispatcher. O WP executa a requisição do usuário. Execução de Web Request: Requisição Web são manipuladas pelo ICM. Estas requisições http(s) podem ser destinadas para o ICF (Internet Communication Framework), o que significa que são executados por um ABAP WP (ex: apl. BSP). Estas requisições também podem ser requisições J2EE para o SAP NW AS Java. O ICM pode direcionar as requisições de acordo com sua URL. Para manter dados seguros, usar conceito de clients que separam dados por clients e conceito de autorizações que separa dados dentro de um client de acordo com o usuário. Alterações para objetos de repositório são client-independent, e imediatamente afetam o ambiente de execução. Entretanto alterações devem ser testadas antes de enviadas para o ambiente produtivo. SAP recomenda três systems landscapes (DEV, QAS, PRD) ** SAP fornece ferramentas para criação, documentação e distribuição dentro de um system landscape. Para configurar o system landscape de modo que ele suporte o gerenciamento, verificação e testes de todas as alterações: Um single client é recomendado para fazer todas customizações; Um single SAP system (DEV) é recomendado para todos trabalhos de

desenvolvimento; Para criar e atribuir autorizações apropriadas para os desenvolvedores e usuários,

use exemplos de profiles incluídas no sistema SAP; Registre e documente todas alterações para um client ou system; ** Client Concept (pg 13)

Dados em um sistema SAP divide-se em duas categorias: Client-specific data, tais como user master e dados de aplicação somente afetam

um client; Cross-client data, tais como cross-client customizing e todos ojetos do repositório

afetam todo ambiente do sistema; Client in na SAP System É uma unidade do sistema SAP que é tecnicamente, organizacionalmente e comercialmente sef-contained. Ele possue seus próprios user master data, application data e Customizing baseado nas table key ranges. Exemplos de client-specific data: User máster data, tal como parâmetros, autorizações grupos de usuários; Customizing data, tal como uma unidade organizacional e tipos de documentos; Application data, tal como dados de negócio transacional, e material máster data; Padrão de clients para atender requisitos mínimos para um sistema SAP: Client CUST (DEV) para configuração de clients e criação de novas funcionalidades; Client QTST (QAS) para testar funcionalidades e cerificar configurações; Client PROD (PRD) para atividades produtivas e dados de negócio; System and Client Change Options (pg 19) SE06 – System Change Option Define se os objetos de customização e de repositório são alteráveis globalmente. Para os objetos que forem (sim), informar se os componentes são. ** Para o software components existem 4 possíveis opções de configuração: Modifiable; Restricted modifiability (pode somente criar objetos como não originais); Not modifiable; enhanceable only (alterações não permitidas, objects podem ser enhanced usando o Enahncement Framework only); Not modifiable; not enhanceable (alterações e enhancements não permitidos); ** Opções de alterações que são encontradas em clients máster na tabela T000, podem ser mantidas utilizando a transação SCC4 – Changes And Transports for client-especific objects. Existem duas definições que devem ser mantidos para implementar controles sobre as mudanças feitas e fazer com que as gravações sejam gravadas para alterar requisições são: 1. Changes and transports for client-specific objects

Changes without automatic recording: permite alteração, porém a change request deve ser feita manualmente

Automatic record of change: alterações geram requests. Ex.: desenvolvimento;

No changes Allowed: sem modificações. Ex.: QAS, PRD; Changes without automatic recording, no transports allowed: permite

alterar, porém não pode transportar. Ex.: Sandbox.

2. Cross-client object changes Changes to repository and cross-client customizing allowed: tudo liberado,

adicionando em requests; No changes to cross-client customizing objects: sem customização, mas

pode desenvolver, adicionando em requests; No changes to repository objects: permite customização, adicionando em

requests, porém não pode desenvolver; No changes to repository and cross-client customizing objects: tudo

bloqueado. Current Settings: quando está tudo bloqueado, alguns valores podem ser alterados, por ex.: taxa de cambio, etc. SAP aprova Current Settings para customizações em objetos que possuem o campo CURSETTING na tabela OBJH. SAP recomenda não fazer alterações na tabela. Quando usar Current Settings na produção: Client role is set to: Production; Cross-client object changes are set to: No changes to Repository and cross-client

Customizing objects; Cahnges and transport for client-specific objects are set to: No changes allowed; Client é uma unidade independente em termos de negócio, organização e dados. Customizing é o setup de dados por client. Cross-client customizing para todos os clients. Repository é o repositório ABAP. Objetos agrupados formam um package. As modificações podem ser de 3 tipos:

Customer Developments: adicionando objetos ao repositório;

Customer Echancements: melhorias adicionadas pelo desenvolvedor, chamadas a partir de user exits ou Business Add-Ins (BAdIs);

Modifications: modificação no objeto original. Ver conceitos no Glossary

Unit 2 - Setting Up na SAP System Landscape (pg 29) Setting Up the Transport Management System (TMS) Após sistema SAP e DB instalados, inicializar via SE06 e configurar o transporte via STMS. Creating a Transport Directory (pg 32) O parâmetro DIR_TRANS do sistema SAP possue o path para o diretório de transporte. UNIX: /usr/sap/trans (default); WINDOWS: \\$(SAPTRANSHOST)\sapmnt\trans - definir o transport host com o alias SAPTRANSHOST no SO do servidor de domínio. Os subdiretórios requeridos no comum diretório de transporte:

bin: configuração arquivos para tp (TP_<domain_name>.PFL) e TMS

(DOMAIN.CFG); buffer: transport buffer para cada sistema; data: dados exportados; cofiles: comandos ou arquivos com informações (tansport type, object classes...); log: transport logs, trace files e estatistics; tmp: dados temporários e log files; actlog: action logs para todas tasks e requests; sapnames: informações para transport requests para cada SAP user; EPS: diretório de download ára support Packages; Logical transport sequence

Fisicamente, objetos alterados em um three-system landscape são transportados em três passos: 1. Todos objetos na (transportable) transport request que estão released são

expotados (copiados) do DB do source system para o diretório de transporte; 2. Estes objetos são importados para o DB do QAS onde serão testados e validados; 3. Após testados e verificados, os objetos podem ser importados para o DB PRD; OBS: Os termo “export” e “import” querem dizer que foi feita uma cópia e não movidos. No final, os objetos existem no DB do DEV, QAS e PRD e no diretório de transporte. TMS: Concepts and Terminology O propósito da TMS (STMS) é centralizar a propagação das alterações através do system landscapes baseado em paths predefinidos. Configuração centralizada do Change and Transport System (CTS) para todos os sistemas SAP.

*** Transport domain: todos os sistemas que usam o mesmo TMS. Devem ter SIDs diferentes e 1 deles é o domain controller. Transport domain controller: sistema onde toda a configuração do TMS é mantida. Alteram-se nele os parâmetros, que são direcionados às outras instâncias. System landscape: conjunto de ambientes que utilizam as mesmas customizações e change requests. Um típico landscape (mas não limitado) é composto de um DEV, um QAS e um PRD. Em muitos casos o system landscape e o transport domain fazem parte do mesmo sistema mas não é incomum ter múltiplos landscapes dentro de um domain transport. Normalmente um landscape = domain, porém pode-se ter + de 1 landscape em 1 domain controler. *** Um transport domain possui pelo menos um transport group, que é um ou mais sistemas que compartilham o mesmo diretório. Configurar o TMS:

1. configurar o domínio, que define quais sistemas estão inclusos no domínio; 2. configurar as rotas, que define sistemas e clients; 3. configurar o QAS com regras de aprovação (opcional).

SAP recomenda que o sistema escolhido para ser o domain controller tenha os seguintes atributos:

Alta disponibilidade Alta precaução quanto a segurança Maior nível de manutenção

Quando usar a TMS após a instalação do sistema, logar no client 000. Para configurar a TMS é necessário a autorização S_CTS_ADMIN. Transação STMS no client 000 irá:

Associar o sistema SAP como o transpor domain controller; Criar transport domain name - DOMAIN_<SID>; Criar transport group GROUP_<SID>; Criar usuário do sistema TMSADM no client 000; Criar RFC destinations; Configurar arquivo DOMAIN.CFG no diretório bin do diretório de transporte;

O transport profile para o programa de controle tp é gerado e armazenado no subdiretório de transporte bin com o nome TP_<DOMAIN>.PFL. Para adicionar novos sistemas para um transport domain, configurar o novo sistema e o transport domain controler. Um transport domain possui pelo menos um transport group, que é um ou mais sistemas que compartilham o mesmo diretório. Backup Domain Controller SAP recomenda configurar um backup domain controller que possa assumir a função de domain controller quando necessário. Este backup deve ser um sistema existente, não pode ser um sistem virtual ou external. Configuring tp (44) O programa tp (transport control) requer um transport profile que contém informações sobre as conexões de todos sistemas SAP no transport domain.TMS gera este tp como parte da configuração do transport domain. Não ajustar este arquivo usando um editor de texto. Para exibir os parâmetros do tp: STMS > Overview > Systems marque um sistema e selecione: SAP System >Display selecione a tab Transport Tool e do menu selecione: Goto > tp parameters. Configuring Transport Routes Transport Routes indica a role de cada sistema e o fluxo de change requests. Rotas definem a regra de cada sistema e o fluxo das change requests. Ela define o system landscape; Para configurar, deve-se modelar as rotas, usando os modelos existentes ou configurar manualmente. Após isto, distribuir e ativar as configurações nos outros sistemas. As configurações das rotas são versionadas, e as versões mais antigas podem ser ativadas novamente. Overview Após as configurações iniciais da TMS como definir os sistemas físicos, domain controller e transport group, o próximo passo é definir o relacionamento de transporte entre cada um destes sistemas.

Após estabilizar o transport domain: 1. Modelar o transport routes do transport domain controlles usando:

Configurações standard (one, two, e three-system lanscape); Editor gráfico para configurações não standard;

2. Distribuir e ativar a nova configuração para todos sistemas SAP dentro do transport domain.

Transport Layers and Transport Routes (pg 47) Transport routes define o fluxo das changes requests de um sistema para o próximo. Estas rotas são chamadas de: Consolidation route: rota “export/import”. Processa um export do DEV para um

import do QAS (three system). Tudo que sai do DEV. Delivery route: rota “another import”. Especificado entre o QAS e o PRD onde não

existe mais um export do QAS mas outro import para o PRD. Tudo que sai do QAS.

Configuring QA Approval Procedure (pg 50) Quando uma request é liberada e exportada o QAS import buffer é populado. Import buffer é uma lista de requests aguardando import. Uma vez que a request é importada dentro da consolidation system, o import buffer para todos delivery system (PRD) é populado. Após liberação (release) de uma change request, no QAS terá uma lista de change requests para serem importadas (import buffer), marcadas como inativas. Apenas após a aprovação do responsável é que estará liberada para sistemas delivery. Com o QA Approval Procedure, é possível marcar as requests como aprovadas no buffer do delivery systems. Objetos originais usam o transport layer “SAP”. Os customizados a “Z<SID>”. DEV = integration system (origem das change requests); QAS = consolidation system (destino da rota de consolidação); PRD = delivery system (destino da rota de delivery).

Uma vez configurada a TMS, realizar alguns testes: Teste de conexão RFC - STMS > SAP System > Check > Connection Test; Checar o diretório de transporte - STMS > SAP System > Check > Transport

Directory; Checar o programa tp (transport control ) - STMS > SAP System > Check >

Transport Tool; Extended Transport Control (pg 60) Originalmente não é possível configurar duas rotas em cima do mesmo transporte layer. Isto porque a package é apontada para um transport layer. A solução para este problema é criar um target group, que contém um ou mais sistemas. O nome do Target Groups deve começar e terminar com “ / “. Client-Specific Transport Control O TMS oferece o Extended Transport Control ( = CTC, client-dependent transport control), que automatiza os processos por: Client-específic transport targets: transporte especifica <SID>.<client> (ex

QAS.100); Client-específic consolidation routes: rotas de consolidação: destino pode ser

um client em um sistema ou grupo de sistemas; Client-específic delivery routes: rotas de delivery. Transport between diferent Transport Groups (64) Sistemas em um grupo de transporte usam mesmo diretório de transporte. Transport between diferent Transport Groups Pode-se utilizar domain links para linkar os dois domains ou external systems para transporte entre transports domains diferentes. Domain link: conexão permanente via RFC, com funcionamento similar ao

transporte convencional. Os logs são apresentados no sistema de destino. External system: utiliza-se outro diretório de transporte, comum aos dois

domínios. Configuration of CTS-Change and Transport System For Transporting Non-ABAP Objects (70) Em um sistema SAP é possível desenvolver em ABAP, J2EE/JEE standard, ou usar uma tecnologia SAP-specific non-ABAP como Web Dynpro Java ou SAP NW Portal. Existem ferramentas para transportar ABAP & JAVA, mas: Não existe sincronização automática para aplicações mistas (como XI), é

necessário usar diferentes ferramentas para transportar partes de uma mesma aplicação;

Não existe uma central de controle de transportes de Portal (além disso ferramentas rudimentares de exportação / importação que estavam disponíveis não foram nem integrados em NWDI nem em CTS-Change and Transport System);

Não existe uma central de controle de todos transportes dentro do sistema produtivo;

Architecture Pode-se configurar o TDC em um sistema Solution Manager (ABAP+Java). Adicionalmente o CTS é configurado. Dentro da transação STMS no TDC (Transport Domain Controler) é possível definir sistemas ABAP e não-ABAP.

Principais passos para configuração no TDC (Transport Domain Controller) System / sistemas baseados no AS ABAP+Java com CTS Deploy Web Service (CTS SYSTEM): ** VER QUESTIONÁRIO PÁGINA 91 **

Unit 3 - Creating and Exporting Transport Requests Definition of Customizing Customizing adapta o software SAP para atender uma empresa individualmente com requerimentos de negócio através da criação de transações de negócios da empresa solicitados no sistema. Customizing Using the SAP Implementation Guide Implementation Guide (IMG): guia para customização em todo ambiente SAP. Provê documentação, e ferramentas para gerenciamento de projetos e documentação. Os projetos podem ser alterados, sobrepondo o projeto anterior, mas mantendo a documentação. O IMG pode ser acessado via transação IMG. Os projetos são cross-client, e podem ser acessados via transação SPRO_ADMIN. O Líder do projeto é responsável por definir e gerenciar o projeto e caso usar o IMG:

Criar o IMG project e o project views; Definir o escopo e a duração; Associar os membros; Definir a linguagem e o tipo de documentação; Definir e manter opções;

Centralização de projetos no Solution Manager permite: Administração e definição do projeto; Administração centralizada do landscape, o que permite aplicar modelos,

centralizar configurações e testes; Através do Business Process Repository, integrado ao SAP Knowledge

Warehouse é possível acelerar a documentação do blueprint; Permite controle central das modificações do projeto e customizações; Criação de planos de testes que refletem em testes seqüenciais e integrados;

Customizações afetam várias tabelas, que são vistas através de table view = tabela virtual, que apresenta dados de várias tabelas.

Tools fr Managing Transport Requests Ferramentas para customizing: Implementation Guide (IMG): tool central para cuidar das customizações. Transport Organizer: guarda as alterações em forma de requests. Transport Organizer é usado para criar, gerenciar, liberar e analizar requests. Acesso via SE09/SE10. Customizações alteram tabelas que são salvas em change requests do tipo customizing, que pertencem somente ao usuário que as criou. Tasks são unidades menores utilizadas pelos customizadores para guardar as mudanças. ** Recomendado pela SAP: Gerente do projeto cria uma change request; Os membros do projeto são adicionados na change request, através de tasks; Cada membro trabalha na sua própria request; Vantagens: Gerente do projeto tem total controle das requests; Objetos nas tasks não podem ser transportados individualmente; Com a liberação da CR o gerente controla quando os objetos são tranferidos para outros landscapes; ***

Quando uma change request é salva, apenas as chaves da tabela são salvas. Quando acontece o export, há a leitura das demais linhas. Customizações podem ser logadas, o que é muito usado para documentação, através da transação SCU3. Caso a change request não seja associada a um projeto no início, é possível associar posteriormente, via CTS (Change and transport system). Quando se ativa funções de projeto CTS em um projeto IMG:

pode-se associar change requests ao projeto; no overview da request pode se ver essa associação; quando se altera customizações no projeto IMG, elas são apenas associadas a

requests do projeto IMG. A associação de projetos IMG à requests pode ser feita de 2 maneiras:

Através da SPRO_ADMIN; Através da SE09, entrando em propriedades e associando o projeto IMG.

Customizing Procedure (123) Em uma implementação SAP, onde customizacões e alterações fazem parte de um sistema, projetos devem ser executados em um ambiente estruturado usando Procedures, para minimizar a inatividade causada por bugs. Roles (papéis): Project manager: cria as change requests e associa os customizadores a ela (criando tasks). Após a customização estar ok, ele libera a change request. Customizer: faz a customização e libera sua task. Tem permissão para copiar as modificações para o client de teste; TMS Administrador: transporta as change requests para demais ambientes.

Algumas transações são classificadas como transporte manual. Elas devem ser manualmente adicionadas à change requests. Antes de se fazer a release de uma change request, realizar testes unitários para testar a funcionalidade da change request e verificar se o conteúdo dela é completo. Testing of Customizing Antes de liberar uma CR, Testar a funcionalidade dentro do Transport Request e Verificar se o conteúdo esta completo.

Criar um client para testes, que permite um teste unitário e testes sem risco de criar dados dependentes de customização. Transação SCC1 copia alterações de um cliente para outro baseado em: Uma task, um Transport Request e uma Trasnport Request e suas Tasks. Testes unitários são feitos em clients TEST onde existam dados. Se uma request contem objetos cross-client, estes objetos não são copiados. Ao copiar uma task para outro client, ela não deve ser liberada, para permitir recustomização caso necessário. Quando uma task é liberada, indica que a customização ou desenvolvimento foi terminado, o teste unitário está ok e a documentação está completa.

Quando a change request é liberada, o conteúdo das tabelas é exportado para o SO e é criada em uma entrada na fila de import no QAS. É possível fazer o merge de change requests, através de utilities > reorganize > merge requests.

Cross Client Customizing Tipos de customização: Client-specific: Customizações típicamente onde o campo client é a primeira posição da chave na tabela; Client-independent: Customizações sem o campo client na chave. Repository objects: tabelas definidas no dicionário ABAP ou programas e relatórios; É possível ver o tipo de customização (dependente/cross) em: IMG > View > Additional information > Technical data Client-dependence. Customizações Cross-client afetam: objetos de customização, gerados pela demanda (objetos do repositório); customizações em opções do sistema, cujas tabelas não contêm o número do

client. Planning Change Management for Development (pg 140) Áreas que devem ser documentadas para o gerenciamento de mudança: Restringir alterações a objetos do repositório:

o Criar 1 sistema para todo desenvolvimento; o certificar-se que as opções de sistema e client estão corretas; o colocar autorizações corretas aos usuários.

Definir padrões de desenvolvimento: o usar pakages; o padrões de documentação e; o manutenção de versões;

definir times de projetos: o treinar sobre os padrões e definir líderes.

Recomendações da SAP:

desenvolvimento em um ambiente apenas;

usar packages para agrupar funções relacionadas a objetos de repositório;

após release da change request, documentar o propósito e o status das modificações;

usar autorizações para controlar perfis;

Customizing versus Development (pg 142) Tools que ajudam na customização: IMG; e no desenvolvimento: ABAP Development Workbench.

Customizing Tools Workbench Tools

Documentação de mudanças

Trabalho em Equipe

Conectado ao Client Adm. e TMS

Alteração no histórico de tabela (logging)

Documentação de mudanças

Trabalho em Equipe

Conectado ao Client Administrator e TMS

SSCR

Packages

Object locking

Version management

O Transport organizer (SE09 ou SE10) pode ser usado para customizing e workbench change requests:

exibe as change requests;

mostra informações globais sobre transport;

provê acesso a tools especiais. SSCR Registration Concepts

Desenvolvedores precisam ser registrados no SSCR para poder criar, modificar ou apagar objetos do repositório. Registrar objetos (originais) a serem alterados (apenas 1x, até upgrade), recebendo um número de licenças para alteração.

Repository objects and Attributes

Customizações começam com Z ou Y, e o nome pode ter um domínio (direcionado a uma package), registrado via view V_TRESN. SAP Repository Object Attributes

Atributos para cada objeto de repositório são associados pelo sistema. O diretório de objetos é armazenado na tabela TADIR. Para alterar entradas na TADIR, usar somente funções standard fornecidas pela SAP. Packages (pg 149) Objetos do repositório são organizados em packages, conhecidos como development class:

provê agrupamento lógico de objetos;

define qual transport layer será usado;

pode controlar nomenclatura de objetos.

Uma package é associada para um Transport Layer; Se o transport Layer é uma Rota de Consolidação válida, os objetos da package são transportados para o sistema consolidado; Objetos SAP modificados no sistema do cliente, seguem a rota de consolidação da SAP; Packages devem iniciar com as seguintes letras:

Y ou Z : package para objetos que serão transportados;

$ : package para objetos temporários que não serão transportados;

TEST : package para objetos, porém ligado ao transport organizer, para prover lock e versionamento.;

A partir do SAP Web AS 6.0, o conceito de packages foi estendido para o conceito de Development Classes. Características das Classes:

Permite o agrupamento em hierarquias, garantindo a segurança;

Permite interfaces com outras classes, desde que elas sejam visíveis;

Definição de acesso de uso. Object Locking (pg 158) Existem dois mecanismos de locking quando objetos do repositório estão sendo modificados:

O Editor de programas, que trabalha com o WP Enqueue para garantir que somente um usuário por vez pode modificar um objeto;

O Workbench transport request, que garante que o desenvolvedor modificará o objeto associado para uma task valida, e apenas pelos desenvolvedores associados a ela.

Releasing Transport Requests Após o desenvolvimento da task ficar completa, uma TR - transport request é liberada de modo que possa ser transportada para outro sistema SAP. Para isso, a task ou TR precisa autorização. Para liberar uma TR, todas tasks devem ser documentadas e liberadas. Version Management (pg 160) Versões de objetos do SAP repositório podem ser comparados ou restaurados. Quando um Workbench TR é liberado, uma nova versão de cada objeto na TP é gravado para uma versão no DB contendo o histórico de todos objetos do repositório. Acessar version management através: SE80, SE09, SE38, SE11, SE37 OBS: Quando criar uma Request, pode-se criar várias tasks para ela. Se liberar a CR, libera automaticamente as tasks associadas, ou pode-se liberar individualmente uma task, mas somente é enviada para o sistema destino. Ex: DEV > QAS, definido na rota de transporte quando liberada a CR) Transport Organizer Settings Trasnsport Organizer tools, é uma coleção de ferramentas que dão suporte ao trabalho com as mudanças do sistema de transporte - transação SE03. Pode analisar componentes como: Objetos, objetos na TR, diretórios de objetos, transport requests e tasks, administração. Transport Organize tools (SE03) provê: - mostrar o erro de transporte ao logar no ambiente; - provê sistema de verificação de objetos antes de ser exportado ao SO.

Após liberar uma TR, consultar o transport log para garantir que o export foi correto:

SE09 >Display > Goto > Transport Logs Códigos indicam que:

0 : sucesso;

4 : warning, mas todos objetos transportados com sucesso;

8 : warning, mas um objeto não pode ser transportado;

12 ou higher : Critical error; Authorizations for Change Management

Na maioria dos casos, a autorização pode ser feito fracionada como mostrado na figura acima.

Superuser (e.g. system administrator) o Has all authorizations related to requests and tasks.

Project leader o Can create and manage requests and tasks.

Developer o Can only use existing requests.

End user o Only has display authorization.

Modifying SAP Objects Objetos de repositório devem somente ser alterados em um sistema SAP onde o sistema identifica os objetos originais, ou seja, o sistema onde o objeto foi criado. Todos outros sistemas podem somente conter cópia do objeto. Alterações em ambiente não padrão de desenvolvimento são chamadas REPAIRS. Transação SE06 controla quais objetos podem ser modificados no sistema SAP. Tipos de change requests ou development tasks:

Transport Requests ou tasks do tipo Unclassified tem a lista de objetos vazia;

Alteração para objetos originais são salvos para tasks do tipo development/correction;

Alteração para cópias são salvos para tasks do tipo repair. A Package de um objeto de repositório determina se a TR é do tipo transportable ou local é requerida. SE95 lista todos objetos modificados no sistema.

Unit 4 - Importing Transport Requests (pg 195) The Transport Process

O TMS pode ser usado para importar toda a fila de change requests exportadas no desenvolvimento. Isto evita que ocorram erros de falta de objetos ao importar uma request (cuja dependente não foi importada) ou que objetos antigos sobreponham os novos. As requests são exportadas para o diretório data e o arquivo de controle no diretório cofiles. No diretório buffer, existe o import buffer file para cada sistema no grupo de transporte (requests e ordem de importação = ordem de release das requests). O segundo passo, TMS executa o tp (transport control program) no SO para importar todas requests listadas no import queue do sistema QAS onde os objetos precisam ser testados de possíveis erros. Caso encontrar erros, devem ser corrigidos no DEV e importados novamente no QAS. Após, as requests são colocadas no import buffer e import queue do sistema PRD. Somente após todas requests terem sido testadas e aprovadas no QAS que serão importadas no sistema PRD. Imports Using TMS (pg 203) Import queues (ABAP) = import buffer (SO) > todas as change requests na ordem que foram liberadas. Podem ser visualisadas/importadas de qualquer sistema do domínio. Para ver a lista de import: STMS > Overview > Imports. Dados da fila são lidos do SO e jogados no banco, pela primeira vez. Para atualizar: Edit > refresh; Refresh executado periódicamente: STMS >Overview > Imports > Extras > Update all Import Queues. SAP recomenda agendar o relatório RSTMSCOL para rodar de hora em hora. Colocando um end mark (import queue) ou um stopmark (import buffer), significa que no import all apenas as requests até ali serão importadas.

Stopmark: Overview > imports > <system> > Queue > Close ou tp setstopmark;

Remove stopmark: Overview > imports > <system> > Queue > Open ou tp delstopmark;

Mover: via TMS ou tp mvstopmark.

Import queue pode ser usada para:

Ver o status das requests;

Acessar lista de objetos, documentação e logs de transporte;

Abrir e fechar a queue, e mover a end mark;

Importar todas requests, um projeto inteiro, requests preliminares (apenas uma request) ou de acordo com seleção de filtro;

Adicionar, remover e passar adiante (outro sistema fora do domínio) requests. SAP recomenda um deadline para release de requests: após este horário, as requests são importadas, setando um end mark, e as seguintes serão importadas apenas no outro horário. Para copiar uma request em um sistema fora do domínio (forward): Request > Forward > System. Cuidado ao apagar requests para não gerar inconsistência de objetos. Melhor corrigir os objetos e gerar nova request. Import all: STMS > Overview > imports > Queue > Start Import. Importa todas requests na ordem que apareceram no buffer/queue. No janela do Start Import existem opções para o import:

Tab Date pode agendar o import;

Tab Execution pode selecionar synchronously ou Asynchronously (Asynchronously: import em background, sessão não fica presa no import;

Tab options, “expert options”; Se uma request de um projeto não for aprovada no QAS, o projeto não pode ser importado na PRD. Apenas as requests aprovadas.

Pode-se desabilitar o import all utilizando o parâmetro NO_IMPORT_ALL. Antes de importar, SAP recomenda usar o end mark para fechar a fila de import.

** Dependendo da escolha para importar (por projeto, individual, all, workflow...) quando iniciar um import pode-se selecionar as seguintes opções na tab Date:

immediate;

at start time: especifica uma hora;

after event: selecionando “execute import periodically”, será processado sempre após um evento, caso contrário só na primeira vez do evento.

** SAP recomenda uso do import all em períodos determinados. Importação freqüente não é recomendada.

Da fila de import de cada sistema SAP pode-se monitorar e manter planejados todos imports selecionando Goto > job Monitor.

Inclusos no transporte:

versões de change requests;

import no mesmo sistema usando SCC1;

import em sistemas seguintes (QAS >PRD). ** Tipos de estratégias de transporte: Queue-controlled mass transports: recomendado quando se tem muitos transportes e se quer automatizar; Single transports: recomendado para transportes controlados (ex.: produção). workflow: para comunicação entre desenvolvedores e administradores do TMS. ** Para selecionar estratégia: abrir rotas de transporte no STMS e efetuar um duplo clique no sistema.

Mass transports: marcando “leave transport request in queue for later import” permite que importações simples sejam novamente importadas em import all.

Utilizar “transport of copies” quando copiar objetos para outros sistemas, mantendo a versão do sistema de origem.

Utilizar “relocations of objects w/o package change” para mover a localização original para outro sistema (ex.: de desenvolvimento temporário DEV).

Utilizar “Relocations of objects with package change” copia os objetos movendo a origem para o sistema de destino, criando sistema de transporte.

Utilizar “relocations of complete package” caso todo o package deverá ser mudado de origem.

QA Approval Procedure and Transport Proposal (pg 225) The TMS Quality Assurance (QA) approval procedure aumenta a qualidade e a disponibilidade dos sistemas de produção permitindo você verificar as TR no QAS antes de liberá-las para sistemas posteriores. Quando o QA approval procedure é ativado, TR são somente encaminhadas para a liberação se todos os passos do QA approval são processados para a request no sistema QA e as requests forem aprovadas.

*** Para o sistema ser configurado como QAS:

Deve ser destino de uma rota de consolidação (iniciando do DEV);

Deve liberar (deliver) pelo menos para um sistema adicional; *** Enquanto todos os steps de aprovação não forem aprovados ou rejeitados, os já escolhidos podem ter sua posição mudada. Ex.: de recusado para aprovado. SAP recomenda não rejeitar requests. Recomenda desenvolver outra que corrija e migrar as duas. Para mostrar a QA Worklist, transação STMS > Overview > Imports > Goto > QA Worklist. Para ver quem aprovou/recusou: Request > Display > QA Status. Para usar o Workflow, SAP recomenda que o sistema que esteja com o Workflow Engine tenha alta disponibilidade, mas baixa carga = QAS. Escolher “Special Transport Workflow” caso o transport seja urgente ou não siga a rota padrão: Utilities > Create transport proposal. Se aprovado, então importa automaticamente e vai um e-mail pra quem solicitou. Se não, vai e-mail informando a recusa, que pode ser rebatido ou cancelado. tp, The Transport Protocol Program tp é usado para controlar transports (export e import) entre sistemas, bem como fazer upgrade de releases. tp é um programa que roda no SO, baseado em C, comandos SO e ABAP no sistema SAP. tp utiliza o R3trans para efetuar comunicação com o banco de dados. Não há mecanismos de import no target imediatamente após o export. Executar o tp via SO (diretório DIR_TRANS/bin com o <SID>adm) deve ser somente em casos especiais, como indisponibilidade do TMS.

Para importar: tp import all <SID> <CLIENT> pf=TP_<DOMAINNAME>.PFL; tp import <REQUEST> <SID> <CLIENT> u0 pf=TP_<DOMAINNAME>.PFL;

Uso do modo “uncondicional” para controle de erro. u0 significa que um transport individual não vai sobrepor objetos mais novos, mantendo ele na fila de imports: 0: requests importadas não são removidas do buffer; 1: ignorar já importadas; 2: sobrepor original; 6: sobrepor objetos em repairs não confirmados; 8: ignorar restrições baseadas em tabela de restrições; 9: ignorar que o sistema está lockado para esse tipo de transporte.

Outros comandos:

tp showbuffer <SID>: buffer daquele SID;

tp addtobuffer <REQUEST> <SID>: adiciona request como última da fila;

tp delfrombuffer <REQUEST> <SID>: remove request do buffer;

tp cleambuffer <SID>: remove requests importadas com sucesso do buffer (intrínseco no inport all). Via STMS: Overview > Imports > Import Queue > Display > Extras > Delete Imported Requests.

- tp setstopmark <SID>: cria a stopmark no final do buffer;

- tp movestopmark <REQUEST> <SID>: marca a request como última da fila;

- tp delstopmark <SID>: remove a stopmark. Import Process (pg 241) R3trans é chamado eventualmente pelo tp e programa de controle de upgrade. A execução do R3trans não é suportada, mas pode ser usada em determinados casos, com pós-atividades necessários. No transporte, utilizar sempre via tp, que chamará o R3trans quando preciso e garantirá todas as atividades completas. Pode exportar em versão velha de R3trans e importar em novo. Pode exportar de um SO e importar em outro SO diferente. Pode exportar de um DB e importar em outro DB diferente. SAP não garante transporte entre releases diferentes de SAP. tp import all: tp setstopmark > importa > tp delstopmark > tp cleanbuffer. Caso haja algum erro no import, após corrigi-lo, o tp recomeça de onde parou. Para cada passo do import: 1. tp passa informações do buffer para o R3trans; 2. R3trans lê os data files e conecta no banco de dados, processando inserts e

updates; 3. R3trans gera log no dir tmp e devolve um exit code para o tp; 4. tp move logs para dir log. tp chama job RDDIMPDP, comunicando via table TRBAT. tp escreve uma linha (header) para dizer ao RDDIMPDP que deve começar o processamento. Dependendo do tipo de atividade, apenas o header é escrito. RDDIMPDP lê a tabela TRBAT e seta a linha do header como “R” (run), inicia programa RDD* (que gera uma entrada na TRJOB) e se auto-agenda. Quando o header da TRBAT é “F” e a TRJOB está vazia, tp copia os logs dos steps concluídos do dir tmp para o dir log e remove entradas na TRBAT. Se o tp detecta problemas nas tabelas TRBAT e TRJOB, inicia um sapevt para reprocessar o RDDIMPDP, que reconhece as entradas nas tabelas e reinicia de onde parou. Após a cópia de um client, o RDDIMPDP é agendado. Para verificar, SM37. Para agendar, o nome do dispatcher é RDDIMPDP_CLIENT_<###>. O evento é o SAP_TRIGGER_RDDIMPDP_CLIENT.

Monitoring Tools (pg 261) TMS fornece várias ferramentas para monitoramento:

Import Monitor;

tp system log

Import queue consistency check;

Transport control program check;

Transport directory check;

RCF connection test. Selecione STMS > Overview > Imports:

Import monitor: para mostrar tp status: goto > Import Monitor;

Import monitor: histórico do import: Goto > Import History.

tp system log: o mostrar todos to calss e erros: SLOG: Goto > TP system log; o código de retorno de todos passos individuais de transport para o corrente

grupo de transporte: ALOG: Goto > Transport Steps. Selecione STMS > Overview > Systems (marque um ou mais sistemas)

verificar o tp: SAP System Check Transport tool;

verificar o diretório de transporte: SAP System Check Transport Directory;

verificar conexões RFC: SAP System Check Connection test. Checking for Critical Objects (pg 263) Existem dois momentos de se fazer a verificação por objetos críticos: 1. Antes do import da change request no destino:

Executado manualmente e é somente um display da lista de TR que contém objetos críticos;

2. Durante o export da TR: automático se parâmetro CHK_CRIOBJ_AT_EXPORT for W (warning) ou E (error).

Para manter lista de objetos críticos: STMS > Overview > Imports > Extras Critical transport objects. SAP recomenda o congelamento de desenvolvimentos durante testes:

Liberar TR com os objetos desenvolvidos;

Congelar o desenvolvimento dos objetos no DEV;

Importar e verificar no QAS ;

“Assinar” as alterações no QAS.

Se necessário, liberar para outras customizações no DEV.

Transport Directory Naming Conventions (pg 267)

Transport Directory Structure and Files Devido o tp rodar em vários SOs, a nomenclatura é restrita: <DEV>K9<5 caracteres>. Subdiretórios do DIR_TRANS:

bin: arquivos de configuração do transport domain;

data: R9<5 digitos>.<SID>: objetos exportados;

cofiles: arquivos de comandos nomeados K9<5 digitos>.<SID> (ex: passos para import);

buffer: import buffer para cada sistema SAP nomeado após o SID;

log: ULOGs, ALOGs, SLOGs, <Source SID><action>9<5 digitos>.<action SID> (step executado) e <action><date>.<action SID> (steps coletivos).

tmp: arquivos de log;

actlog: <source SID>Z<6 digitos>: grava ações na request (criação, modificação, release);

sapnames: <USER>: registro de ações de usuários;

EPS (Eletronic Parcel Service): conte, o diretório in, para qual Support Packages são copiadas para serem aplicadas com SPAM.

Transação AL11 consulta diretórios. Troubleshooting transports (PG 269) Durante o import é usado o dir tmp, depois é movido para log. Os arquivos de log possuem nome <source SID><action><6 digitos>.<target SID>. Níveis de detalhes dos logs, visualizados no SAP: - ações e códigos de retorno; - mensagens de erro adicionais; - logs de usuário; - detalhes para desenvolvedores e hot-line.

Logs criados pelo tp: ULOG: cada linha representa um comando livre de erro; SLOG: monitora as atividades de transporte de um sistema; ALOG: todos os códigos de retorno de steps num mesmo diretório de transporte. tp recebe códigos de retorno de todas tools envolvidas em um processo de import:

0 a 16: valor máximo todos códigos de retorno da ferramenta de transporte;

17 a 99: calculado dos códigos de retorno das ferramentas de transporte e tp warnings;

100 a 199: indica warnings. Até 149 são “normais”, após isto indica operação incorreta pelo usuário;

200 ou mais: erro. Para verificar erro: 1. STMS > Monitor > Alert viewer; 2. Informações mais detalhadas no SLOG; 3. ALOG apresenta steps cujos códigos de retorno estão no SLOG; 4. Verificar se o job RDDIMPDP está agendado e se é iniciado por eventos. 5. Comparar coteúdo das tabelas TRBAT e TRJOB com o import buffer (SM31). Cleaning Up the Transport Directory

tp check all: procura por requests que não estão marcadas para import;

tp clearold all: usa o comando acima para ver requests que passaram da idade máxima.

Parâmetros de idade máxima: datalifetime (move para dir olddata), olddatalifetime (apaga do dir olddata), cofilefiletime (apaga do dir cofiles), loglifetime (apaga do dir log).

Unit 5 - Client Tools (pg 307) Using Client Copy and Transport Tools

Client Copy pode copiar os seguintes componentes do source para target client: User master data: só apaga dados no destino se um profile com user master data

é copiado. O copy profile SAP_USER contem authorization profiles e roles; customizing: todos profiles exceto SAP_USER contem customizing. Tabelas

classe C, G, E e S. Cross-client customizing: para outro sistema; master/transacion (application) data: criar um client de teste a partir de um client

de produção. Tabelas classe A; Testes a serem feitos antes de liberar uma request:

testar funcionalidade; verificar se o conteúdo é completo.

Manter cliente separado para testes permite: teste unitário verdadeiro; teste sem risco de criar dados que dependam de customização;

SCC1 permite copiar (a partir do destino): uma task; uma change request; uma change request com suas tasks.

SCC1 - Cópia de client baseada em uma Change Request. Entrar no source client e TR para ser copiado. Somente uma change request pode ser copiada por vez. As change requests podem ser agrupadas em outra, para migrar tudo de uma vez.

Local client copy Copia de clients de um mesmo sistema SAP.

1. SCC4 para criar novo client; 2. Setar login/no_automatic_user_sapstar=0 e logar no destino com SAP*/pass; 3. Etrar na SCCL e importar dados; 4. Atribuir ao source client para customizing data, application data e user master

records; 5. Iniciar a cópia. Se for um grande processo utilizar background;

Caso o parâmetros login/no_automatic_user_sapstar=1 não permite conectar com SAP*. ** Para assegurar consistência nos dados, não logar no client destino durante a cópia de client. SAP também recomenda não trabalhar no client origem durante a cópia. SAP entrega o software com client 000 standard, mas não é aconselhável trabalhar neste client. Pode-se usar o client 001 se ele existir. Client 001 é uma cópia do client 000. Entretanto, se não existir client 001, SAP recomenda que inicie a implementação criando um novo client com uma cópia do 001. ** Remote client copy

Copia de client para outro sistema SAP (SCC9): - Não precisa de espaço em disco, vai via RFC; - cross-client customizing objects podem ser migrados juntos; - tabelas devem ser iguais nos dois ambientes. ***| Podem ser usados com vários múltiplos processos paralelos, acelerando o processo. Outros fatores importantes que devem ser levados em conta, incluem performance de rede e DB; Processos de cópia são gerados em momento de execução por processos de RFC paralelos, gerenciados pode servers group. Deve-se especificar o máximo número de processos para usar na cópia; Para especificar o máximo número de processos de cópia, usar transação SCCL para cópia local, ou SCC9 para cópia remota (Goto > Parallel Processes); Para definir um server group, SM59 > Extras > RFC Groups. *** Client transport

Utilizado para copiar dados entre diferentes clients, não usa RFC, mas gera arquivo no dir de transporte, via SCC8. Arquivos gerados:

RO<number>: contém dados client-independent; RT<number>: dados client-específic; RX<number>: contém textos SAPsripts.

Não é importada via import all, mas pode ser importada via TMS. Após o import process, logar no target client e executar SCC7 para pós-atividades. Client Delete (pg 318)

Logar no client que será deletado; Transação SCC5; Iniciar a deleção em processo background;

Client Copy Profiles SAP entrega todas profiles necessárias para client copy ou client transport. max online runtime (rdisp/max_wprun_time) deve ser grande o suficiente. Recomendado > 2000segs; Para estimar o tamanho de um client, executar o programa RSTABLESIZE.

Monitoring Transação SCC3 mostra todos arquivos de logs das cópias. Informa:

estatísticas de tabelas; controle de informação; informações sobre cada tabela copiada.

Quando executado qualquer transação com prefixo SCC, gera arquivo de log no diretório usr/sap/trans/log Verificar não só o log da cópia, mas também do sistema (RFC com problema, etc.). Re-execução recomeça de onde parou. Para checar possíveis problemas:

SCC3 - copy log; SM21 - system log; ST22 - dump analysis; SM37 - job overview; SP01 - spool;

Client Compare and Maintenance Tools

A função de compare (SCU0) serve para ver diferenças de tabelas ou views entre clients diferentes, usando RFC. Usos:

comparar client com o client de referencia (000, por exemplo); comparar clients durante um cenário de rollout. comparar customizações cross-client antes de combinar clients (roll in).

*** No compare, pode-se usar uma visão orientada a projeto, via IMG. Podem-se selecionar componentes da aplicação, objetos customizados e TR, bem como selecionar objetos manualmente. *** A informação mais importante é o status (comparision status) que indica a existência e a natureza das diferenças. Process status indica os que já foram comparados ou não. Apenas um objeto pode ser alterado por vez, e aqueles que são alterados via SM30. Os demais apenas comparados. Via SCC4, configura-se o nível de proteção do cliente: Protection level 1: no overwriting: não pode ser sobreposto, mas pode sofrer

compare. Protection level 2: no overwriting and no external availability: não sobrepõe e

não aparece em compare (PRD).

Unit 15 – Note Assistant, SAP Support Packages and Upgrades SAP Note Assistant Notas podem fornecer informações sobre produtos, parceiros e clientes da SAP, bem como correções. A nota inclui:

sintomas do erro; causa do erro; descrição de como corrigir o código; a versão e support package necessários; links para support packages que resolvem o problema.

SAP NOTE: implementa automaticamente notas que modificam códigos ABAP; cuida da dependência com outras notas, support packages e modificações; mostra todas as notas implementadas no sistema; corrige apenas um bug, sem alterar ABAP Dictionay Objects, e não substitui SP. Pode-se aplicar o SAP Notes de duas maneiras com o SAP Note Assistant: 1. Se uma conexão com o SAP Service Marketplace estiver configurado, realizar

diretamente o download para seu sistema; 2. Realizar separadamente o download do SAP Service Marketplace (ex: Download

Manager) e então fazer o upload para o sistema. Alterações no código original não requerem chave SSRC. Aplicar na DEV > transportar para o QAS via TMS, não aplicar diretamente no QAS > importar na PRD. Acessando a transação SNOTE, é apresentada a worklist pessoal, diferente do Note Browser. Note Browser é um overview de todas as notas existentes no sistema.

Note Assistant provê: Exibição de informações de notas direcionadas para seu usuário, notas

inconsistentes (todas) e notas novas; Pesquisa por notas; Download de notas; Verificação de notas para verificar seu status; definir o status de aplicação da nota.

Notas podem ser implementadas/removidas (Cancel SAP Note Implementation). Para fazer download do SAP Note http://service.sap.com/notes com o SAP Download Manager disponível no SAP Service Marketplace. Pode-se classificar a nota, bem como direcionar a aplicação para outra pessoa. Para aplicar, selecionar “Implement SAP Note”. Será solicitado que salve as alterações em uma change request. Antes de importar, execute uma syntax check. Um log é gerado após a aplicação da nota. Caso seja necessário aplicar outras notas antes da escolhida, e havendo conexão direta com o SAPNet, serão apresentadas as outras notas não aplicadas. Caso haja necessidade de modificações, na aplicação da nota pode ser direcionado ao Modification Browser (SE95). Support Packages (pg 370) Um sistema SAP consiste de diferentes componentes de software que sofrem atualizações usando SP. Corrigem vários erros em vários componentes. Antes, o SP deve ser importado via download do SAP Service Marketplace. Correções de erros e novas funcionalidades dos layers (SAP_BASIS, SAP_ABA, etc.) são implementados via support packages. SPAM, ferramenta para aplicar SP. SAINT, install e upgrade nos Add-ons. Antes de usar estas transações, atualizar o patch com um SPAM/SAINT update. Import Process Realizar um import dos SP requer um longo tempo de sistema inativo (downtime). Para downtime minimized import, onde report sources e report texts são importados com o sistema ativo (reduz de 70 a 80% no ECC). SPDD para objetos do Dictionary Repository SPAU para outros objetos do Repository. SAP System Upgrade

Antes de realizar o upgrade, deve-se analisar o por quê: técnico, estratégico, etc: qual o custo total do upgrade? o upgrade trará vantagem financeira para mim (payback/ROI)? Quais os benefícios do upgrade? Quais os riscos envolvidos? Itens a serem pensados no planejamento do upgrade: Release de customizações; modifications; adaptação e testes de melhorias de usuários; adaptação e testes de interfaces; adaptação e testes de formulários; treinamento do usuário final; testes e validação de novos releases. A maior parte do projeto de upgrade é adequar os processos do negócio às novas funcionalidades do sistema. Atividades técnicas a prever: requerimento de hardware; sizing e configuração; planos de SO, DB, Kernel e upgrade de sistemas SAP; testes e validação de backup da nova versão; tecnical upgrade de todo o system landscape; atividades pós-upgrade, incluindo acompanhamento de performance. Quando decidir por qual versão SAP irá fazer o upgrade, considere: Estratégia da liberação do SAP; Custo de upgrade e manutenção de IT; Custo para adaptar processos de negócio; Requerimento de negócio X Funções SAP; Custos X Payback/ROI; Um upgrade técnico envolve: tomar decisões sobre a estratégia de upgrade e a conversão de tabelas. Planejar

as modificações para minimizar o downtime; requerimentos de software, hardware, SO e BD devem ser vistos antes do

upgrade; após realizar as atividades de PREPARE, iniciar o upgrade; PREPARE são atividades para verificar se o sistema pode receber o upgrade.

Testes e ações manuais podem ser feitos antes do upgrade; realizar o upgrade; atividades pós-upgrade. Ferramentas para auxiliar o upgrade: Prepare: faz verificações no sistema, como SP e Add-ons, e importa outros tools

para o upgrade; ICNV (incremental table conversion): tool importado pelo PREPARE responsável

por trabalhar mudanças na estrutura de tabelas. Upgrade Assistant: processa independentemente de um certo front-end; Upgrade Monitor: monitora o upgrade e ajuda a identificar onde está parado.

Estima quanto tempo falta. SGEN: feito upgrade a cada versão.

Fases do upgrade: PREPARE: Preparação antes do upgrade; EU_IMPORT: import do novo repositório (como um Shadow repositório); DIFF: Cópia de todas modificações, desenvolvimentos próprios, SP, Add-nos para

o Shadow; ACT: SPDD; ICNV; SHADOW_IMPORT; EU_SWITCH, KX_SWITCH (switch); PARCONV,PMVBTAB(switch); TABIM(switch); XPRAS(switch); Durante a fase de switch, o sistema estará em período não produtivo. Se objetos precisam de ajuste, use transação SPDD e SPAU. Alterações feitas na SPAU e SPDD devem ser incluídas (não importadas) no upgrade da próxima base. Todas as modificações são perdidas, sobrepostas em novos objetos. Elas devem ser refeitas nesses novos objetos. A lista de objetos que precisam ser ajustados é gerada na fase ADJUSTPRP, durante o PREPARE. As modificações devem ser feitas durante o downtime, antes da ativação de objetos do dicionário ABAP. São agrupadas em uma request, que não sofre release, mas é marcada como export na SPDD. Objetos não devem ser manualmente ativados. Eles serão ativados nas fases corretas. Após o upgrade, são concedidos 14 dias para execução da transação SPAU sem necessitar de SSCR em objetos modificados anteriormente.

Unit 7 - Advanced User Administration Topics Introduction to CUA - Central User Administrator Caso você possua um grupo de sistemas e o mesmo usuário existir em vários clientes, é possível reduzir o custo para manter usuários em diferentes sistemas SAP, utilizando o CUA. Clássico cenário com múltiplos sistemas.

Conceito: O objetivo do CUA é reduzir o custo, parâmetros de administração de usuários e centralizar o trabalho com mais segurança. O objetivo do CUA é utilizar somente um simples client para manter dados de usuário. Pré-requisitos para uma implementação eficiente de CUA: Existe um grande número de usuários idênticos em múltiplos sistemas; Existe um system landscape complexo com grande número de clientes para ser

gerenciado; Reduzir custos complexos, distribuir administração de users com CUA; Usuários devem ser bloqueados, e não excluídos. Central deve ser 4.6C pra cima; Cliente pode ser 4.5B pra cima.

Setting UP a CUA (pg 409)

8 Check transfer logs Transaction SCUL

User Administration with the CUA Após o CUA habilitado, algumas diferenças: nova tab Systems: mostra os sistemas em que o usuário está cadastrado. Se

removido desta tela, remove do ambiente; Roles page: contém as roles do cliente. Executar o Text comparison para atualizar

lista; Profiles: idem roles; Introduction to Directory Services Directory Services age como um repositório central de usuários. As informações são gravadas de forma hierárquica (tree). Acesso normalmente via LDAP, X.500 DAP ou DSML. Exemplo de um Cenário com um Directory Service

LDAP - Lightweight Directory Access Protocol. Ele descreve como operações serão formuladas para um diretório de serviço. A operação mais comum é resgatar entradas, no entanto, também é possível criar, alterar ou excluir entradas. De um ponto de vista técnico, LDAP segue o modelo cliente / servidor: um ou mais servidores asseguram a informação que o cliente acessa. Originalmente, LDAP implementadas somente comunica com um servidor X.500, como descrito pela International Organization for Standardization (ISO). Utiliza pilhas TCP/IP; Contém entradas que são um ou mais atributos; atributos estão em Classes, que fazem parte de um Schema. Entradas estão organizadas em árvores (chamada Directory Information Tree – DIT), e cada entrada possui um Distinguished Name (DN), que é criado descrevendo o caminho do root da árvore. SAP & LDAP Na versão 4.0A foi disponibilizado o LDAP Gateway, programa instalado a parte. Na versão 4.6A foi disponibilizado o LDAP Connector, integrado ao AS, interface entre o AS e o LDAP Server. Desde o Web AS 6.10 foram disponibilizadas funções para sincronização de dados CUA and Directory Services

Technical Connection of Directory Services (pg 460) SAP usa RFC do tipo T (TCP/IP). Se só existe um ambiente no servidor, usar RFC com nome LDAP_<SERVIDOR>, caso tenha mais que um, utilizar LDAP_<SERVIDOR>-<SEQN>. Letras maiúsculas e sem espaço. Necessário registrar no gateway local (sapgw<instance number>). Transação LDAP ou SPRO > SAP NetWeaver > SAP Web Application Server > System Administration > Directory Integration. Quando o Status do servidor LDAP é determinado como ativo no SAP, o CCMS monitora frequentemente o status do LDAP. Necessário usuário para acessar o LDAP (ou acesso anônimo). Esse usuário não corresponde a usuário no SAP ou no Directory Server. O user pode estar cadastrado no SAP, porém aqui é salvado um user diferente. Após isto, configurar o Connection Data, com informações sobre o servidor LDAP.