Iniciando sua carreira como SAP Basis

Olá, escrevi o conteúdo abaixo com o intuito de ajudar profissionais de TI que estão iniciando sua carreira como SAP Basis.

Tópicos:

  • Objetivo do ebook
  • O que é SAP
  • Mercado SAP
  • Módulos e consultores SAP
  • Arquitetura do Sistema SAP
    – Instância SAP
    – Banco de dados e Sistema Operacional
    – Usuários de SO e de Banco
    – Tipos de Processos
    – Application Server JAVA
    – SAP Router
  • Administração do sistema
    – Iniciando e parando o sistema
    – Administração de Usuários
    – Administração de Roles
    – Configuração de parâmetros
    – Application Servers
    – Modos de Operação
    – Jobs
    – Mensagens do sistema
  • Monitoramento de Sistemas SAP
    – Checklist diário
    – Monitorando Banco de dados
    – Dumps
    – System Log
    – Envio de e-mail
    – Table Locks e Updates de tabelas
    – Status dos Work Process
    – Application Server Status
    – Spool
  • SAP Support Portal
    – O que é?
    – Procurando Notas para soluções
    – Abrindo chamado na SAP
    – Gerando chaves de desenvolvedor e de Objetos

Objetivo do ebook:

Este ebook tem como objetivo lhe ensinar os principais conceitos na teoria e na prática de um Administrador de Sistemas SAP, para você que é estudante da área de TI ou já atua na área. Não existem muitos cursos para esse tipo específico de profissional, e os que existem são extremamente caros, portanto neste ebook você terá a chance de dar os primeiros passos no caminho do tão desejado mundo SAP.

Veremos a seguir os principais tópicos básicos de uma forma clara e objetiva, onde os assuntos foram trazidos de verdadeiras experiências do dia a dia de um consultor SAP. 

O que é SAP

A SAP é uma empresa alemã, que iniciou suas atividades na cidade de Walldorf, na Alemanha, em 1972, e hoje possui inúmeras filiais espalhadas pelo mundo, inclusive no Brasil. SAP significa Systeme, Anwendungen und Produkte in der Datenverarbeitung (em inglês: Systems, Applications and Products in Data Processing, em português: Sistemas, Aplicativos e Produtos para Processamento de Dados).

A medida em que você se aprofundar tecnicamente no sistema SAP, não estranhe os nomes de tabelas ou transações, na maior parte das vezes elas tem seu significado em alemão :). 

A SAP tem inúmeros produtos no mercado hoje em dia, precisamos ressaltar que quando nos referimos ao sistema SAP, estamos falando de algum deles em específico. Um dos principais é o SAP ECC, muito utilizado por várias grandes empresa. 

Mercado SAP

Este talvez seja um dos motivos por você estar lendo este ebook. O mercado SAP é conhecido como um dos mais valorizados na área de Tecnologia. E esta afirmação é correta, basta olharmos alguns números no site Love Mondays por exemplo:

https://www.lovemondays.com.br/salarios/cargo/salario-consultor-sap

Este é um mercado  ……

Módulos e consultores SAP

Os consultores SAP são divididos em três áreas: 

Funcional

São os consultores que trabalham com as definições da regra de negócio do sistema, neste encontramos por exemplo os módulos MM (Material Management), FI (Financial Accounting), CO (Controlling) entre outros.

Desenvolvimento

O SAP é construído em cima de sua própria linguagem de programação, chamada ABAP (Advanced Business Application Programming). Com conhecimento nessa linguagem, os desenvolvedores podem fazer alterações em programas standard, criados pela SAP, e podem construir programas totalmente novos dentro do SAP, criando telas, tabelas e etc. É muito difícil haver um implantação do sistema SAP sem a necessidade dessa customização, sempre há alguma regra nova, ou a mudança de uma para atender a necessidade do cliente.

Infraestrutura

Aqui se encontram os Administradores do sistema SAP, conhecidos como Basis. Eles são responsáveis pela instalação, configuração e manutenção de todo o sistema. É comum analistas de outras áreas como banco de dados, e sistemas operacionais migrarem para a área de SAP Basis. Além de ser responsável por manter o ambiente SAP funcionando de forma eficiente, o consultor Basis também deve cuidar de tarefas críticas como Disaster/Recovery, migrações, upgrades do sistemas, além de tarefas mais administrativas, como criação de usuários, definição de roles etc.

Arquitetura do Sistema SAP

A arquitetura dos sistemas SAP é baseada em Client/Server de três camadas: apresentação, aplicação e dados. Em termos de hardware significa que há um Servidor em uma rede que disponibiliza os dados e recursos para os Clients. Os clients ou workstations executam chamados ao servidor SAP, que após serem processadas retornam com o resultado, basicamente todo o processo ocorre na parte servidor.

A conexão dos usuários com o sistema SAP é feita através do programa SAP GUI (SAP Logon).


Na camada de dados, quem tem o controle é o SGBD (sistema gerenciador de banco de dados). Existem alguns bancos de dados com suporte ao SAP como Oracle, SQL Server e SyBase ASE. Alguns deles irão perder o suporte e homologação SAP em alguns anos, como o Oracle, porém hoje em dia ainda é um dos SGBDs mais usados. Tudo isso para que a SAP expanda seu mercado com o bando HANA, que por sinal deve ser um dos seus futuros assuntos para estudo.

A camada de aplicação, entrando um pouco mais em detalhes é baseada em um sistema chamado Netweaver, que é o próprio servidor de aplicação. É nele que são instalados os componentes de negócio que são necessários para determinada empresa.

Instância SAP

O termo “Instância SAP” é todo o conjunto que vimos na imagem anterior. Ela é identificada pelo SID (System ID) e um número de dois dígitos por exemplo PRD e 01. Estes são definidos em sua instalação. É através deles que se baseiam por exemplo o nome dos usuários criados no sistema operacional, banco de dados, e também os diretórios criados no sistema, portanto o ideal é ter cautela na definição deles, para que correspondam com suas funções, como por exemplo DEV para sistemas de desenvolvimento e QAS para sistemas de qualidade. É dessa forma “geralmente” que você encontrará os sistemas em clientes.

Banco de dados e Sistema Operacional

Os arquivos do sistema SAP ficam por padrão abaixo do diretório /usr/sap, tanto no windows como no linux, e abaixo dela você encontra a pasta <sid> de cada sistema instalado neste determinado servidor, por exemplo /usr/sap/DEV.

Algumas configurações e verificações particulares são necessárias ao instalar o sistema SAP, seja no Linux ou no Windows, e para isso existem Guides da própria SAP que devem ser seguidos a fim de manter o sistema rodando de forma eficiente. Os guias de instalação podem ser encontrados no link abaixo.

https://help.sap.com/viewer/nwguidefinder

Exemplo:

O banco de dados de um sistema SAP pode ser instalado no mesmo servidor ou em um servidor diferente, isso vai depender da carga de trabalho desse sistema. Em um sistema Oracle, seu principal diretório será o /oracle e abaixo dele a pasta <SID>, por exemplo /oracle/DEV.

Uma das tarefas do profissional SAP Basis é o gerenciamento de espaço, no Oracle, quando falamos de forma física, as informações ficam em arquivos chamados datafiles, nas pastas /oracle/<SID>/datafile1…datafile2, e assim por diante. De forma lógica, dentro do banco as informações ficam contidas em tablespaces, dependendo de sua configuração, estas precisam ser aumentadas manualmente. Falaremos mais dessas atividades nos capítulos posteriores.

As atividades no Oracle, quando possível, e por muitas vezes necessárias devem ser realizadas através do aplicativo BRTOOLS, que é uma ferramenta criada pela SAP para o gerenciamento do Banco. Nele o administrador pode fazer alterações de senhas de usuários de banco, adicionar mais espaço ao banco, fazer backup etc. 

Usuários de SO e de Banco

Os usuários criados na instalação de um sistema SAP são o <sid>adm, que é responsável pela aplicação, e o ora<sid> que é o usuário responsável pelo banco de dados. Neste caso o “ora” no usuário responsável pelo banco vem de Oracle, esta nomenclatura muda de acordo com o Banco de Dados.

Na última versão do banco Oracle homologada para o SAP, o 12c, existe a opção do usuário de banco ser “oracle” e não ora<sid>, portanto você deve se atentar a esta diferença caso o banco esteja nesta versão. 

Existe também um usuário muito importante que é usado pelo SAP para acessar os dados de dentro do Oracle, chamado por padrão SAPSR3, deve se ter cuidado ao gerenciar este usuário, pois qualquer alteração pode causar a parada do ambiente SAP.  

Tipos de Processos

No sistema SAP os processos, ou seja, onde acontecem as execuções dos programas são chamados de Work Process, ou WP. Existem cinco tipos de Work Process:

Dialog: são os processos que executam as requisições dos usuários, tudo aquilo que é mostrado na tela para um usuário através do SAP GUI é executado por work process do tipo Dialog. Estes são geralmente a maior parte dos work process.

Background: como o nome já diz, são nestes tipos de work process que o SAP executa seus programas Batch, aqueles que não tem interação com o usuário.

Update: executa as solicitações de atualização ou alterações do banco de dados assíncrono controladas por uma instrução COMMIT WORK em um processo de trabalho de dialog ou background.

Spool: passa fluxos de dados sequenciais para Impressoras ou Formatação de Impressão para impressora, arquivo ou banco de dados.

Enqueue: administra a tabela de bloqueios na memória compartilhada ou Se as transações do SAP tiverem que se sincronizar, elas executam operações de bloqueio.

Através da transação SM50, você pode verificar os status atuais de todos os processos:

Application Server JAVA

SAP Router

O SAP Router é um aplicativo, não muito complexo da SAP que possibilita os sistemas ligados a ele ter uma conexão direta com a SAP. Essa conexão possibilita algumas facilidades ao ambiente, como por exemplo, o download de Notas de correções diretamente no seu sistema, e também a conexão de profissionais da SAP quando você abre um chamado ao suporte.

Uma outra função, também muito importante que pode ser usada com o SAP Router é a conexão ao sistema por usuários pela internet, funcionando como um Firewall, tendo um servidor onde ele está instalado, que é onde as requisições chegam, e a partir dele direcionando para os servidor dos sistemas. 

Informações para a instalação e configuração do SAP Router: 

https://support.sap.com/en/tools/connectivity-tools/saprouter/install-saprouter.html

Administração do sistema

Iniciando e parando o sistema no Linux

Uma das tarefas mais básicas de um administrador de sistemas SAP é baixar e subir o sistema quando necessário, seja por uma manutenção no próprio SAP ou sistema operacional. Ele deve ser executado com o usuário <sid>adm.

comando para iniciar:

su – <sid>adm
startsap

comando para baixar:

su – <sid>adm
stopsap

Por padrão esse comando deve iniciar/para o sistema e o banco, porém você pode utilizar as variáveis abaixo para aplicar o comando de formas diferentes.

startsap R3 (inicia apenas o sistema, e não  banco)
startsap DB (iniciar apenas o banco, e não o sistema)

startsap ALL (inicia ambos) 

O mesmo vale para o stopsap.

Importante lembrar que após de um restart no servidor de banco de dados, por exemplo, é preciso iniciar o listener do banco com o comando abaixo. Sem o listener estar em execução o SAP não irá funcionar.

su – ora<sid>
lsnrctl start

Caso ocorra algum problema durante o start do sistema, você pode verificar mais detalhes nos logs, na pasta /usr/sap/<SID>/DVEBMGS<sid-Nr>/work. Nesta pasta você encontrará vários tipos de logs, os logs com W0, W1, W2… e assim por diante se referem a cada work processes, os logs STDERR são arquivos criados durante a inicialização do sistema.


Uma dica é usar o como “ls -ltrh” no linux, para ordenar os arquivos editados recentemente, quando estamos fazendo um troubleshooting.

Administração de Usuários

A principal transação para administrar usuários no SAP ‘ea SU01. Nela você pode criar, editar e deletar os usuários do sistema.




Abaixo um exemplo da tela ao criar um usuário. As principais abas que devem ser levadas em consideração além da primeira aba “Address”, são “Logon Data” onde você precisa definir uma senha inicial para o usuário, no primeiro logon do usuário, o sistema irá solicitar a mudança da mesma. Outras Abas importantes são as “Profiles” e “Roles”, você precisa definir pelo menos um Profile para o usuários poder logar no sistema. Quais Roles e quais Profiles vão depender da função do usuário no sistema, que em geral são desenhados pelo time de segurança.

Ainda na aba logon data, você deve definir o tipo de usuário. O tipo Dialog é o Default, como o nome já diz, estes têm permissão para processos do tipo Dialog. O tipo System pode ser usado para executar tarefas em background assim como o Service.



Apesar de ser uma atividade simples, a atribuição de Roles e Profiles requer atenção, pois você pode estar atribuindo uma ação ao usuário que ele não necessite e que pode até ocasionar em um problema no sistema, como por exemplo o privilégio de “DEBUG”, onde alguém com certos conhecimentos pode apagar ou alterar registros das tabelas. No caso do sistema de produção isso pode gerar uma extrema dor de cabeça.



Exemplo tela SU01

SAP_ALL

SAP_ALL é uma profile onde os usuários administradores do sistema são atribuídos. Pois permite muitas ações no sistema, como atualização, alteração de parâmetros, tarefas de banco de dados e etc. 

Geralmente é atribuída nos sistemas de Qualidade e desenvolvimento para o time de Basis. Em produção o ideal é criar um Profile com as tarefas de administrador.

Administração de Roles


A administração de Roles no SAP é feita pela transação PFCG. 

Para criar, editar ou deletar uma Role, basta colocar o nome dela, procurar com a tecla F4.

Clicando em “Single Role” você cria uma nova Role, vamos dar o exemplo de criação de uma Role onde o usuário necessite ter acesso a criação de usuários. Para isso, na nova tela você vai na aba “Menu” e clica no botão “Transactions”. Após isso preenche o campo “Transaction Code” com a transação desejada, no nosso caso SU01.

Após isso, é necessário definir quais ações dentro desta transação a Role dará privilégio. Isso pode ser feito na aba “Authorizations”, no botão “Change Authorization Data”.

Aqui podem ser definidas o que o user com esta Role poderá fazer.

A tarefa de administração de Roles podem ser bem complexas dependendo do tamanho da empresa que está utilizando o sistema, pois pode depender até de algumas leis do País em questão. Por exemplo, caso a empresa tenha empregados de outro país, podem haver leis que obrigam a certas informações não estarem disponíveis para estrangeiros, desta forma as Roles precisam estar conforme tais obrigações.

Configuração de parâmetros

Ao iniciar o sistema SAP, este busca seus parâmetros, como quantidade de memória, nomes e etc em dois arquivos que ficam por padrão nesta pasta /usr/sap/<SID>/SYS/profile. Os arquivos são o default profile (DEFAULT.PFL)  e o profile referente a instância (<SID>_DVEBMGS00_sapserver). Em versões anteriores do sistema existia ainda um terceiro arquivo, chamado de Start profile, porém ele não existe mais nas últimas versões.

Exemplo da pasta:

Os arquivos com numeração são backups de últimas versões dos arquivos.

a sequência de leitura dos profiles quando o sistema é iniciado, é primeiro o DEFAULT.PFL e depois o <SID>_DVEBMGS00_sapserver. Você pode facilmente editá los através do sistema operacional, porém isso não é recomendado, pois desta forma não como rastrear as alterações feitas.

Para fazer a alteração de um parâmetro, ele deve ser feito através da transação RZ10, com ela podemos manter as versões antigas dos arquivos, e restaurá-los se necessário.


no primeiro acesso a esta transação de um sistema recém instalado, provavelmente você não encontrará os profiles, sendo necessário fazer o impor deles do servidor conforme abaixo:

Após esse procedimento, você conseguirá abrir os dois profiles do sistema.

Para verificar ou alterar parâmetros, é necessário selecionar a opção “Extended maintenance”

O profile Default contém alguns parâmetros mais gerais do sistema, com o nome do banco de dados, os diretórios do sistema, portas e assim por diante. Enquanto o profile da instância contém algumas configurações voltadas a um “ajuste mais detalhado” para o funcionamento do sistema.


No profile da instância, você define por exemplo quantos work process de cada tipo vão existir no sistema:

Existem outros parâmetros que podem não estar nesses arquivos, mas que podem ser adicionados, dependendo da sua necessidade. Ai vale uma pesquisa para saber se existe tal parâmetro que você precisa. 

Alguns parâmetros necessitam da reinicialização do sistema e outros não. Uma dica importante é: caso você altere um parâmetro, e no momento da reinicialização do sistema aconteça algum erro que o impeça de subir, você deve ir até a pasta do perfil via sistema operacional e voltar a última versão.


Caso você já saiba qual parâmetro deseja alterar ou verificar seu valor, você pode ir direto consultar na transação RZ11. Basta escolher ou digitar o parâmetro e clicar em display. Exemplo:


Application Servers

Application Servers são servidores adicionais que ajudam ao balanceamento da carga de execução lógica de programas do sistema SAP. Todo sistema SAP tem uma Central Instance e partir dela podem ser adicionados novos servidores de aplicação. Nestes outros servidores adicionais o administrador irá configurar conforme a necessidade a quantidade de Work Process de cada tipo.

Você consegue verificar todos os Apps servers na transação SM51:

A pasta “/sapmnt/<SID>/” deve estar compartilhada no servidor central “Central Instance” e mapeada em todos os outros servidores adicionais de aplicação. Isso é necessário para que os servidores adicionais possam ler seus perfis na pasta profiles, e também os arquivos de Kernel, que ficam na subpasta exe. Desta forma quando ocorrer uma atualização de Kernel na CI, todos os outros servidores receberão a mesma atualização. 

Modos de Operação

Os modos de operação, ou “operation mode” servem para maximizar a utilização de recursos de ambiente SAP em determinados horários. Por exemplo, nos horários noturnos geralmente não há muitos usuários logados utilizando o sistema, o que significa menor processos do tipo Dialog sendo executados. Por outro lado, a noite é onde a maioria dos processos Backgrounds como jobs são executados.

Com esta função podemos alterar a distribuição dos tipos de Work Process em determinados horários de forma pré agendada. Por exemplo, durante o dia utilizar 10 WPs do tipo Dialog e 3 do tipo Background, e durante a noite fazer a inversão, 3 do tipo Dialog e 10 do tipo Background, assim mais jobs poderiam ser executados ao mesmo tempo durante esse horário.

Para esta configuração são utilizadas as transações RZ04 para a definição dos Operation Modes, ajustando em cada um a distribuição dos Work Process, e na transação SM63 a definição do horário de início e fim de cada um.

Abaixo exemplo da RZ04 com dois modos cadastrados:

Com um duplo clique, é possível verificar a distribuição:

Exemplo de agendamento na SM63:

Jobs

Jobs são processos que executam sem interação do usuário. São usados bastante no SAP, além de vários Jobs padrão que já são configurados após uma instalação, eles são utilizados em larga escala por processos de negócios, o que torna o monitoramento deles de suma importância para a empresa.

Como administrador do sistema, você deve estar ciente de quais jobs estão com problemas, atrasos ou rodado sem erros. Mesmo não sendo a tarefa do administrador resolver algum job que possa estar exibindo um erro, como por exemplo um processo funcional customizado, você deve fazer a primeira análise e se certificar de que o erro não aconteceu por algum problema de infra estrutura. 

Muitas vezes o ideal é solicitar ajuda de um consultor ABAP ou Funcional, dependendo da situação, para que juntos possam achar a causa raiz e aplicar a solução. 

As principais transações para os Jobs são SM36 para criar os jobs e SM37 para analisar e alterar.

Na SM36, em um sistema novo, você precisa configurar os jobs standard, indo nessa opção:

Depois em Default scheduling:

Após essa execução, você verá na lista todos os jobs schedulados:

Uma dica aqui, ou talvez uma “obrigação” é você criar um usuário do tipo Dialog, e depois de fazer os agendamentos altere para System, apenas para esses tipo de tarefas standard do sistema, pois imagine se você ou alguém de sua equipe faça o agendamento desses jobs, e após algum tempo esse usuário seja bloqueado por tentativa de senhas erradas ou algo do tipo. O resultado será todos os jobs deste usuário sendo cancelados. 

Para criar um novo Job customizado, use a opção Job Wizard, ela irá guiar a configuração.

Abaixo estão os tatus possíveis dos jobs:

Os nomes já são auto explicativos. 

Na transação SM37, podemos procurar, ver detalhes, e alterar o status dos jobs:

Para alterar, basta selecionar o job desejado, e ir no menu “Job”, e você terá as opções possíveis:

Por vezes necessitamos saber qual programa o job está executando, para isso basta clicar duas vezes no job e depois ir no botão “Step”. Exemplo:



Mensagens do sistema

Uma simples dica. Quando temos a necessidade de fazer uma manutenção no sistema, ou qualquer outra ação que afete os usuários, você pode cadastrar uma mensagem que irá aparecer para o usuário dentro do SAP.

Para isso utilize a transação SM02:

Basta ir no botão “Create” e cadastrar uma mensagem conforme necessário.

Remote Function Call (RFC)

As RFCs são configurações de destinos por onde o sistema SAP pode se comunicar com outro sistema SAP ou outro sistema legado qualquer.

Essas configurações são feitas através da transação SM59:

Abaixo podemos ver todos os tipos possíveis de conexões, porém a mais utilizada será a ABAP 3:

O sistema já vem com algumas RFCs estabelecidas, como por exemplo para executar programas de dentro do próprio servidor. A configuração de Transporte de Requests, que é utilizada para transportar programas de desenvolvimento para Qualidade e Produção também necessita de determinadas configurações de RFC. 

Caso você enfrente algum problema de conexão, é possível fazer o teste no botão “ “Connection Test”, dentro da RFC.

Outro teste válida é esse feito na opção Utilities:

O Authorization Test é de suma importância, pois testa além de verificar se o servidor está respondendo, também se o usuário que está configurado na RFC tem as permissões necessárias para o acesso.

Muitos erros ocorrem por causa de usuários que estão configurados na RFC porém foram bloqueados, ou alterados no sistema de destino. 

A configuração do usuário pode ser feito na aba “Logon & Security”:

Monitoramento de Sistemas SAP

Checklist diário

Uma das tarefas que todo administrador tem é manter a boa “saúde” do sistema através de uma verificação diária. Hoje em dia existem tarefas automáticas para monitorar o ambiente SAP através do Solution Manager, que é outro sistema da própria SAP que auxilia em toda a parte de gerenciamento de um landscape SAP. Porém em clientes não muito grandes, por vezes não há nenhuma configuração desse tipo, devido ao custo. 

Também é possível fazer o monitoramento através de desenvolvimento de programas ABAP, RFCs e funções, porém haverá custo para esse desenvolvimento.

Nos próximos tópicos, veremos algumas transações que devem participar desse monitoramento e veremos um pouco mais de cada uma.

 Monitorando Banco de dados

A principal transação para tarefas de administração do banco de dados é a DBACOCKPIT:

Aqui temos várias informações separadas por pastas ao lado esquerdo. 

Uma das principais tarefas no banco de dados, é acompanhar e monitorar o espaço usado atualmente. Para isso verifique sempre a utilização das tablespaces:

Também verifique no DBA Calendar, ou transação DB13, se os jobs do banco estão executando com sucesso:

Na opção database check é necessário avaliar as mensagens de alertas. Algumas podem necessitar de uma ação do DBA ou mesmo do Administrador SAP:


Dumps

Quando um programa do SAP, qualquer um, sendo um “Z” ou um standard termina em um erro técnico, ele irá gerar um DUMP, ou seja, um log com todas as informações desta parada inesperada do programa. 

Os dumps podem ser consultados na transação ST22:

No topo da tela já temos a quantidade de dumps gerados entre ontem e hoje. Essa verificação tem maior importância em sistemas produtivos, pois nos sistemas de desenvolvimento e qualidade é normal terem uma quantidade relativamente alta de DUMPs, pois estes sistemas servem para este fim. Mesmo assim, é importante ter um controle destes dumps em todos os ambientes, pois alguns deles podem estar sendo gerados por uma falha de configuração do sistema.

É necessário verificar os detalhes dos dumps, muitas vezes precisamos de suporte dos consultores funcionais ou abaps. Antes de encaminhar o erro para um consultor de outro módulo, certifique-se que você não pode dar apoio para a correção do mesmo.


Exemplo de erro onde são indicadas notas para a correção:

System Log

O system log é acessado através da transação SM21. Se trata de um log mais aprofundado de algumas ações ou comportamentos do sistema, como por quando o sistema é reiniciado, ou o operation mode é alterado automaticamente, essas ações ficam registradas neste log.

Exemplo:

Essa transação é utilizada na maior parte do tempo relativamente, ou seja, quando se está analisando algum problema no sistema, e ainda não se sabe a causa, este log pode ajudar a identificar a causa.


Envio de e-mail

O SAP tem uma configuração para enviar e-mails automaticamente. Este envio pode ser acionada por programas customizados ou standard, como por exemplo enviar uma informação para um fornecedor.

A configuração de e-mail deve ser feita na transação SCOT. Nela é configurada a porta e o endereço do servidor de e-mail. As vezes é necessário configurações externas no servidor do SAP e também no servidor de e-mail como Relay por exemplo.


Uma vez configurado o envio de e-mails, todos os e-mails que devem ser enviados seguem para uma caixa de saída, que pode ser verificada na transação SOST. Nesta transação pode ser verificado o status do e-mail, se foi enviado, se aconteceu um erro e etc.


Table Locks e Updates de tabelas

Além dos locks de tabelas feito pelo próprio Banco de dados, o SAP possui seu próprio mecanismo de lock, para evitar que duas transações alterem os mesmos dados simultaneamente. Você pode verificar o status dos locks atuais na transação SM12.

Normalmente esses locks são adicionados e deletados automaticamente, ou deveriam ser. Porém podem ocorrer casos em que o usuário estava atuando em alguma transação e por algum motivo sua conexão caiu. Nesse caso é possível que o Lock fique “pendente”, até que alguém libere o mesmo na transação SM12:

Como administrador do sistema, você deve de tempos em tempos verificar se há algum lock muito antigo, e a partir daí analisar se o mesmo pode ser liberado. 

Para verificar os comandos Updates com erro e atuais, é utilizada uma transação semelhante, a SM13. Geralmente ela deve mostrar uma tabela vazia, caso mostrar algum erro você deve analisar mais a fundo o ocorrido.

Status dos Work Process

Para verificar o status de todos os workprocess, você pode utilizar a transação SM50 que terá como resultado a tela abaixo:

O importante aqui é verificar se não há uma ocupação total de um tipo de work process. Como por exemplo, se um job que roda em um intervalo muito curto, e este mesmo estiver travando por algum motivo, logo todos os Work Process do tipo Background estarão ocupados e impossibilitando qualquer outra rotina de job ser executada. 

Alguns sintomas de Work Process “Cheios” são a impossibilidade de alguns usuários estarem logando no sistema, e a interrupção de alguns processos como por exemplo o de importação de Requests. Nesses casos iniciar a análise pela SM50 pode ser uma boa ideia.

Se você contëm mais de um Application Server, inicie essa verificação pela transação SM51, pois nela você irá primeiramente selecionar o app server, e ao dar dois clique no mesmo, cairá na SM50 deste server.

A transação SM66 também pode ser usada caso você queira verificar os processos ativos. 


Caso exista algum work process travado, ou de algum usuário que já deslogou do sistema, você pode cancelar o mesmo através das opções abaixo, que podem ser utilizadas tanto na SM66 quanto na SM50.


Application Server Status

Utilize a transação SM51 quando tiver vários applications servers em seu ambiente. Nela você pode verificar o status de cada um deles. Pode acontecer de um app server estar fora do ar e você não perceber no princípio, pois o sistema funcionará normalmente.


Spool

O processo de spool é utilizado para saída de documentos que foi selecionado para impressão, mas ainda não foi impresso e fica temporariamente armazenado nesta área até que seja enviado para seu destino final. Nesta área também é possível visualizar as informações contidas dentro dele. No caso dos jobs que retornam informações, estas ficam no spool e podem ser visualizadas na SM37.

SAP Support Portal


O que é?

O portal da SAP é a conexão que você como cliente tem com a SAP. É através dele que será solicitado suporte quando necessário, irá fazer download de mídias para atualizações e etc. Abaixo veremos algumas das atividades.

O portal pode ser acessado através do link: https://support.sap.com

O login é feito pelo “S User” que compõem de uma numeração começando com a letra “S”. Na tela inicial você pode ver as principais funções. No campo de busca principal, pode ser pesquisado por qualquer assunto, como por exemplo um erro em dump que você encontrou, como também um arquivo de download que você necessita para alguma atualização:



Por vezes você pode se depara com um problema no sistema que seja um bug da própria SAP, ou uma nova funcionalidade que é necessária para os usuários, mas que ainda não é possível utilizar por falta deste processo. 

Nesses casos a SAP disponibiliza Notas de correção, que vão fazer os ajustes necessários. A aplicação das notas será abordada em um tópico mais a frente.

Caso você não encontre uma nota de correção para o seu problema, você pode abrir um chamado para a SAP explicando o ocorrido. Esta comunicação é feita em inglês. Indo um pouco mais além, a SAP pode solicitar acessar seu ambiente para verificar o seu problema. Para que este acesso da SAP funcione, é preciso que o seu sistema esteja configurado no portal e tenha acesso através de uma conexão feita geralmente pelo Solution Manager, e depois “abrir” o ambiente para a SAP neste portal:



Outros consultores, de outros módulos também podem possuir seu acesso ao portal, pois eles próprios podem tratar seus chamados com a SAP e procurar notas.

Gerando chaves de desenvolvedor e de Objetos

Este tópico também é uma atividade do administrador do sistema no Portal da SAP. Quando é criado um usuário no sistema, onde o mesmo tem a função de desenvolvedor, ao tentar criar um programa por exemplo, será solicitada a ele uma chave de desenvolvedor. Esta chave é gerada no Portal da SAP, onde deve ser informado o usuário e alguns detalhes do sistema como instalação, versão e etc.

Da mesma forma, quando é necessário fazer uma customização em um programa standard da SAP, você precisa ir na mesma área dentro do portal e gerar esta chave, para depois passar para o Desenvolvedor responsável.

Product Availability Matrix

Em determinado momento, você receberá projetos de novas instalações ou migrações de ambientes para novos Sistemas operacionais, Hardware e banco de dados diferentes, ou mesmo um novo ambiente de qualidade ou desenvolvimento. É muito importante o planejamento antes da execução destas atividades, e um passo importante é a verificação na Matrix disponível no Portal.

Nela encontramos os produtos certificados para determinada versão do sistema SAP, como Kernel, Sistema Operacional, Banco de dados e etc, além de informações como a validade do suporte.

Licenças

O controle de licenças no SAP pode ser verificado na transação SLICENSE. Ao instalar um sistema do zero, o mesmo vem com uma licença temporária, que logo deve ser substituída. Existem dois tipos de licenças, a permanente, e a “maintenance”. Basicamente, a licença permanente permitirá que o sistema seja acessado, e a licença “maintenance” deixa o sistema disponível para atualizações e upgrades. 

A licença “maintenance” expira de tempos em tempos, e deve ser atualizada gerando uma nova através do portal da SAP informando alguns dados como o Hardware Key e o Installation Number. 

Um processo que pode invalidar a licença, é uma migração de servidor, pois o hardware key irá ter um número diferente na nova máquina.