TADM10 - PARTE 2 / 2

Unit 1 - Technology Components for Browser-Based User Dialogs Internet Scenarios with SAP Systems 1. SAP Basis 3.1G - Internet Transaction Server (SAP ITS)

2. As of SAP Web AS 6.10: Openness Using the ICM (Internet Comunication Manager)

ICM utilizado para processar requisições HTTP (e outros protocolos) diretamente para a internet. O processo ICM encaminha requisições para o ICF (Internet Communication Framework), que suporta vários modelos de programação. Isto é como o CRM, SAP BW, e SAP XI usam esta infraestrutura.

3. AS Java

Com o AS Java, o SAP possue uma completa compatibilidade com aplicações J2EE em vários produtos. O SAP NW AS fornece as opções de instalação:

SAP NW AS ABAP (AS ABAP) SAP NW AS Java (AS Java) SAP NW AS ABAP+Java (AS ABAP+Java)

Exemplo de componentes de software que usam J2EE: Portal, SAP PI (Exchange Infrastructure), SAP CRM 4. Web Dynpro

O modelo de programação do Web Dynpro é disponível para Instances Java e ABAP.

Internet Communication Manager (pg 19)

Características: Suporte a HTTP(S), SMTP, SOAP, WebDav; Output em XML, HTML e XSLT; integração completa com o SAP

Funciona como Web Server e Web Client. Junto com o Work Process, o Internet Communication Framework (ICF) prove o ambiente para manipular requisições HTTP. ICF é a ponte entre o kernel do SAP e aplicações criadas em ABAP. O Work Process pode enviar uma resposta web via ICM. Para isto, as aplicações são desenvolvidas em BSPs (SE80). O ICM é um processo a parte (icman), baseado em threads, iniciado e monitorado pelo dispatcher ABAP. Componentes do ICM: Thread control: recebe a entrada TCP/IP e direciona ao thread pool; Worker Thread: manipula as requisições e respostas. Contem I/O handler para

input e output e plug-ins para cada protocolo (padrão: HTTP(S) e SMTP); Watchdog: work thread espera por uma resposta do usuário. Caso dê timeout, o

watchdog libera a thread para processar outra requisição; Signal Handler: processa sinais enviados pelo SO ou outro processo; Connection Info: informações sobre todas as conexões; Memory Pipes: permite transmissão de dados entre ICM e ABAP work process.

ISC: Internet Server Cache É a parte mais importante do ICM referente a performance pois armazena objetos HTTP(S) após envio ao Web browser. Funcionalidades: Two-level hierarchy:Hierarquia em 2 níveis, Cache em memória e disco; Dynamic caching: Cache para BSPs e JSPs; Active caching: Aplicação tem controle para verificar se o cacha está atualizado; UFO caching: (UnFound) requisições inválidas são rejeitadas, evitando ataques; Browser-dependent caching: Cache dependente de browser, usa cache apenas para um tipo de navegador especificado no BSP. ISC é configurado via parâmetros icm/HTTP/server_cache* Parâmetro rdisp/start_icman determina qual instância terá o ICM. Para detalhes e monitoramento: transação SMICM. Em Administration > ICM pode-se parar. Colocando Restart > Yes/No indica se é para reiniciar (devido a erro) ou deixar parado (manutenção). Atividades do /nSMICM: Monitora e reinicializa o ICM; Configura nível de trace (valores 0 a 3); Avalia os arquivos de trace; Overview dos parâmetros; Mostra estatísticas; Monitora e Reseta o ICM Server Cache; O programa icmon no SO exibe mais detalhes do ICM (icmon –h para help). Internet Communication Framework Permite a comunicação entre sistemas diferentes através de protocolos standard (http e SMTP) da internet. Nenhuma biblioteca adicional é requerida, exceto para HTTPS (sapcryptolib).

O Task Handler recebe a requisição, executa alguns processos e responde a request. Caso a requisição deva ser direcionada a um Work Process, o Task Handler inicia um ICF controller. A partir daí, está no mundo ABAP.

Uma requisição http(S) é processada conforme os passos: 1. Usuário manda requisição HTTP. O ICM usa a URL para determinar se a aplicação

chamada é ABAP ou JAVA; 2. ICM guarda dados na memory pipe e avisa o ABAP dispatcher 3. ABAP coloca a requisição no dispatcher queue, cria o contexto e seleciona um WP 4. o task handler lê os dados do memory pipe e transfere para o ICF controller 5. ICF controller transfere para o ICF Manager 6. usuário é autenticado 7. a requisição HTTP é processada e o controle é devolvido para o ICF controller 8. o task handler escreve o resultado na memory pipe e sinaliza ao ICM que a

resposta está pronta 9. ICM devolve a resposta para o Web browser; O ICF é uma classe ABAP por trás da requisição HTTP. A SAP disponibiliza algumas classes. Outras podem ser criadas no Class Builder (SE24). Todos os serviços são exibidos e mantidos na transação SICF. Serviços ativos são exibidos em preto, enquanto os inativos em cinza. Em azul os que são ativados/desativados de acordo com o serviço pai. A alteração das propriedades dos serviços é feita na forma de herança (mudou o pai, os filhos também são mudados), exceto quando o filho é alterado manualmente. O ICF cria links (ou alias) entre um serviço e outro. O ICF Recorder permite a desenvolvedores ou administradores a identificar e corrigir erros em solicitações HTTP. A request com problemas pode ser reexecutada várias vezes usando a entrada no banco de dados. Para acessar o ICF Recorder: SICF > Edit > Recorder > Activate Recording/Deactivate Recording/Display recording, ou transação SICFRECORDER para exibir o trace. Na hora de ativar o trace: determinar a URL, o tempo de duração e se uma ou mais requests serão gravadas. Até 6.20, o ITS era Standalone. A partir do 6.40, está imbutido no kernel (integrated). Na 6.40, o ITS é acessado via processo ICM, implementado como serviço ICF e usa o banco de dados como object store. Restrições:

o integrado não suporta o flow logic, WebRFC e WebReporting. Para isso necessário ITS 6.20;

um ITS standalone não pode sofrer upgrade para o integrated. Apenas via upgrade do Web AS.

Para ativar o ITS integrated:

ICM deve estar rodando; paramentro itsp/enable=1; o serviço ITS deve estar publicado no site interno; ITS service está ativo e o ICF e propriedade GUI Link=Y; serviço ICM /SAP/public/BC/its/mimes está ativado e ICF e propriedade GUI

link= “ ” (espaço). Outros parâmetros iniciam com itsp/*. Especial atenção para:

itsp/enable: ativa o ITS integrado; em/global_area_MB: shared memory para todos Work Processes + integrado

ITS. Além destes parâmetros, existem parâmetros de serviços, mantidos via SICF. Um desenvolvedor pode criar um novo serviço via Web Application Builder for ITS Service (SE80), e publicá-lo no site INTERNAL.

Para usar o SAP GUI for HTML, é necessário ainda: serviço system e webgui publicados no site INTERNAL; serviço ICF /SAP/BR/gui/SAP/its/webgui ativado, com o GUI Link=Y. O

monitoramento é feito via SM21, SM22, SMICM e SMICF, e os logs estão junto dos logs dos Work Process (dev_w*.trc).

SAP Web Dispatcher (pág 65)

O Web Dispatcher é usado como centralizador de conexões e como load balance. Age como um Web switch. É uma solução SAP para requisições load distribution for HTTP(S). Se um sistema SAP possue múltiplas Instances, o SAP Web Dispatcher recebe as requisições do browser e encaminha para o servidor de aplicação que possuir mais capacidade. 1) O Web Dispatcher identifica se a chamada é ABAP ou Java, e qual logon group a ser usado; 2) O load balancing é feito no grupo. É necessário um Web Dispatcher por sistema. O SAP Web Dispatcher é somente relevante em um ambiente WEB. Quando um SAP GUI for Windows ou SAP GUI for Java é usado, o ABAP Message Server (MS) distribui o load. Funções do SAP Web Dispacher (SAP WD) SAP WD encaminha uma requisição HTTP(s) para um AS específico. Esta requisição é associada ao server em dois estágios:

1. Determina se a próxima solicitação HTTP será enviada para um ABAP ou a um Java server e localiza um server group para executar.

2. O load balance é então realizada dentro deste grupo. Em seguida a requisição para ICM do servidor correspondente.

Um SAP WD pode distribuir requisições para somente um sistema SAP. Server Selection SAP WD checa se a requisição é um ABAP ou J2EE analisando o prefixo da URL. O valor do parâmetro /HTTP/default_root_hdl determina o destino. ABAP request utiliza um cookie para identificar se a requisição é uma aplicação stateful. O controle sobre sessão stateful é feita via cookie (usa sempre o mesmo AS). Se é stateless, é usado um logon group !DIAG ou !J2EE. AS Java também reconhece o conceito de logon groups. Para Java request o SAP Web Dispatcher utiliza o internal group !J2EE. Se é uma aplicação stateful, ela é declarada pela Session Info na URL ou load balance usando um cookie. Por razões de compatibilidade, jsessionid cookie da sessão também pode ser utilizado aqui. Load Balancing SAP Web Dispatcher obtem informações sobre o AS do sistema SAP a partir do MS via HTTP(S). O SAP Web Dispatcher pode ser usado com sistemas ABAP, ABAP+Java e Java puro.

A configuração do Web Dispatcher é feita basicamente em 3 parâmetros:

icm/server_port_<X>: porta do Web Dispatcher; rdisp/mshost: host do message server; ms/http_port: porta do message Server.

A interface HTTP do MS permite visualizar informações do AS com um Web Dispatcher (lista de comandos do MS). http://<message server with domain>:<massage server port>/msgserver/commands

Ex: http://<host>:<porta MS>/msgserver/command Operating the SAP Web Dispatcher A estrutura interna do SAP Web Dispatcher é baseada no processo ICM. Utiliza um arquivo de profile para configurar as opções de Start. Para usá-lo, copiar o executável (sapwebdisp.exe) para um host, junto com o profile. Ativando em modo bootstrap (sem arquivo de profile: sapwebdisp –bootstrap: se não existir o profile sapwebdisp.pfl, ele é criado; se o arquivo de autorização icmauth.txt não existe, ele é criado e um usuário para administração é criado; o Web Dispatcher é ativado com o profile criado. Outra forma de ativar: sapwebdisp pf=<profile>. Para desativar, executar o kill. Monitoring Monitorado via ICMON. A SAP disponibiliza uma interface de administração e monitoramento baseado em web. As entradas no icmauth.txt podem ser alteradas via icmon –a. Para chamar a interface do Web admin: URL: http://<server with domain>:<SAP Web Dispatcher port>/<Admin prefix> Obs: <Admin prefix> definido através do parâmetro icm/HTTP/admin_<xx>. Utilizar o HTTPS para segurança.

Load Balancing in the SAP Web AS Java Environment Server-Based Load Balancing Um Load Balancing atua como uma entrada central para o sistema SAP, mesmo se o ele é constituído por múltiplos servidores de aplicação. Vantagens:

Todos servidores de aplicação podem ser endereçados usando um IP ou um nome comum;

Os usuários sempre usam a mesma URL para acessar o sistema; Um certificado SSL é suficiente para todos os AS; Reduzir o esforço e custo de manutenção e operação;

Client Based Load Balance: cliente se conecta a um servidor, que devolve a informação do servidor “oficial” a ser usado. O cliente então direciona a comunicação para este servidor. Desvantagens: confusão devido muitas URLs, uso de favoritos, necessidade de vários certificados de segurança (1 por servidor), abertura no firewall.

Stateless and Stateful Web Applications Dois modelos de programação para aplicações Web: Stateless: usado para aplicações simples onde cada requisição para SAP NW AS é independente de todas outras requisições; Stateful: usado para aplicações mais complexas baseadas em um conceito transacional.

Realization of Load Balancing in SAP Web AS Java

Em um cluster com múltiplas instances SAP NW AS Java, load balancing é executado usando um Load Balancer conectado no front (1). Dentro da instance Java o Java Dispatcher (2) distribui as requisições para os Server Process onde ele está conectado. Load Balancing Between Many Java Instances

O SAP Web Dispatcher é entregue com a Central Services (Enqueue Service e Message Service). Encontrado em: /usr/sap/<SID>/SCS01/exe

Unit 2 - Basics of User Administration AS ABAP User Master Record: Contém a definição de um usuário particular no client. Alguns campos são nome, número de telefone e senha inicial. É utilizado para criar o user context quando um usuário efetua logon no sistema. (ver user context pág 655) Usuários são associados a Roles. Tipos de users:

Dialog: efetua logon; usuário normal para todos tipos de logon; System: não efetua logon, não troca senha, usado para batch, RFC, ALE,

Workflow, TMS, etc. Communication: não efetua logon, setup de senha (validade, etc.), usado

para comunicação entre sistemas Service: usado para acesso anônimo via ITS, com baixas permissões,

permitido múltiplos logons, etc. Reference: referencia para criação de novos users.

Transação para manutenção: SU01 Os dados são divididos nas seguintes tab pages:

Address: Dados de endereço; Logon data: Validação, tipo de user; Defaults: Valores padrão para printers, language, etc; Parameters: User-specific - valores para campos padrão; Roles and Profiles: Roles e profiles associadas ao user; Groups: agrupamento de usuários para manutenção em massa;

Autorization Concept Ações e acesso a dados são protegidos por authorization objects, que são formados por object classes, que permitem determinada ação. Quando se cria um menu com as transações em uma role, as autorizações vêm juntas. Necessário verificar manualmente. Ao associar user X role, não necessariamente começa a funcionar. Necessário fazer um “user máster comparison”, que pode ser feita na: Role Maintenance: Menus and Authorizations Transação PFCG cria autorizações e associa aos users. Uma role pode ser associada a vários users e users podem ser associados a várias roles. Role Maintenance cria automaticamente as autorizações associadas com as transações especificadas na árvore de menu, entretanto, todos os valores devem ser manualmente checados e ajustados se requeridos. Green trafic light: indica que a manutenção da role pode criar automaticamente uma autorização. Yellow traffic light: indica que a autorização deve ser mantida manualmente após ele ter sido criado. Red traffic light: indica um nível organizacional mantido; Users and Roles A associação dos usuários para as roles é mantida na /nPFCG ou /nSU01. Users podem ser lincados com mais de uma role. A associação de roles para users não ocorre automaticamente, deve-se primeiro realizar uma user master comparison. Esta comparação determina se o profile de autorização deve ser adicionado ou removido do user corrente. Comparação em massa /nPFUD.

O job PFCG_TIME_DEPENDENCY garante que os períodos de validade serão verificados (schedular job manualmente-SM37). Login Parameters and User Info System Profile Parameters for User Logons: login/min_password_lng: tamanho mínimo da senha. De 3 (default) a 8 caracteres; login/min_password_digits: quantidade mínima de dígitos; login/min_password_letters: quantidade minima de letras; login/min_password_specials: quantidade minima de caracteres especiais. login/password_expiration_time: 0 (default) a 999 dias. login/password/max_reset_valid: tempo em que a password alterada por administrador é válida. 0 a 24000 dias. login/password_max_new_valid: tempo em que a primeira senha é válida. 0 a 24000 dias. login/fails_to_session_end: x vezes errado fecha sessão. 1 a 99. Padrão: 3. login/fails_to_user_lock: quantidade de vezes erradas para bloquear usuário. 1 a 99. Padrão: 12. login/failed_user_auto_unlock: se desbloqueia usuário na virada do dia: 0 ou 1 (default); login/disable_muilti_gui_login: usuário pode logar mais de 1 vez no mesmo client. 0 (default) ou 1. login/multi_login_users: lista de user separados por vírgula q são excluídos da regra acima. Passwords:

Não pode ser = últimas 5; Não pode começar com ?, ! ou espaço; Não pode ser “pass”; Não pode começar com 3 caracteres iguais.

Initial Passwords for Standard Users Durante instalação de um sistema SAP são criados os clients 000 e 066 (o client 001 nem sempre é criado; pode ser criado durante uma instalação do ECC). User SAP* tem por default senha PASS. Um usuário master record é criado automaticamente para SAP* no client 000 (e 001 se existir). User DDIC é responsável por manter o Dictionary ABAP e o software logistics. Um usuário master record é criado automaticamente para DDIC no client 000 (e 001 se existir). SAP recomenda associar estes usuários (SAP*, DDIC) ao grupo SUPER (superusers) no client 000 (001). User Early Watch criado no client 066 (pass SUPPORT) usado para funções de Monitoramento e Performance. Recomendações para o user SAP* Se você copia um client, o user SAP* esta sempre disponível. Não possue um user master record. Para proteger seu sistema contra acessos indevidos, criar um user master record (superuser) para este usuário standard. (pág 138 para mais detalhes). Transação SUIM: overview de user master records, autorizações, profiles, roles, etc.

SU53: mostra as autorizações que faltam para que o usuário possa completar a última ação. ST01: Grava authorization checks de sessões.

Unit 3 - User and Authorization Concept AS Java User Management Engine UME

A UME é uma aplicação Java executada no SAP NW AS Java. É uma interface para guardar dados de usuários. DBMS provider: armazenamento no sistema DB. UDDI provider: armazenamento através de prestadores de serviços externos; iniciativa para descrever serviços e integrar negócios via internet. (Universal description, Discovery and Integration). UME provider: Conexão de integração User Management Engine. Default, serviço do Web AS Java, administração central de usuários. Administra usuários no banco de dados, serviço de diretório ou ABAP. Características:

console de administração, com facilidades de administração (criação de users e grupos, associação de roles...);

políticas de segurança para usuário (tamanho da senha, etc.); cenários de auto-atendimento: workflow de autorização, alterar os próprios

dados, registrar-se como novo usuário, etc; dados de usuários podem ser trocados com outros sistemas (AS Java ou

externos) usando o export/import; logs de segurança

Architecture

A UME é apenas uma interface para guardar dados de usuários e suporta uma variedade de data sources onde os dados de usuário possam ser armazenados:

System Database (Java) Diretório de Serviços (LDAP server - cadastro da rede) ABAP-based SAP System (SAP Web AS)

UME Core Layer: Fornece persistence managers entre as interface de programação de aplicação e o user management data sources. Data Partitioning UME oferece a opção de armazenar dados de usuários em diferentes data sources. Interfaces: persistence manager: permite guardar dados em fontes diferente. Define qual dado estará em qual data source; replication manager: gera um XML e manda para um sistema externo. Tipos de particionamento: Attribute-based: um campo (telefone, nome, etc.) é guardado em uma origem, outro campo em outra origem; User-based: um tipo de usuário em um (ex.: terceiros) e outro tipo de usuários em outro; Type-based: ex.: usuários no sistema e roles no LDAP. Configuring the Data Sources Configurar os data sources armazenados no AS Java Database na forma de arquivos de configuração (no formato XML). Durante a instalação do AS Java podem ser escolhidos 2 tipos de acessos:

AS Java (sem ABAP): Data source - system database (configuração do arquivo dataSourceConfiguration_database_only.xml) - para centralização via java ou outro AS ABAP;

ABAP + Java: Data source - ABAP system (configuração do arquivo dataSourceConfiguration_abap.xml) - onde o java acessa o repositório do ABAP.

As seguintes alterações são suportadas:

System Database: Permite alterar entre LDAP e ABAP System; ABAP System: Não permite alterações; Directory Service : Permite alterar a estrutura para outro LDAP diferente;

Tools for UME (User Management Engine) Configuration UME Administration Console: através do Web Browser para modificar

configurações sem conhecimento dos parâmetros (path: URL /username > Configuration) http//<hots>:5$$00;

Configuration Tool (Offline Configuration Editor Mode): somente offline para acesso a todas configurações da UME. (path: cluster_data > server > cfg > services > Propertysheet com.sap.security.core.ume.service);

Configuration Tool (simple mode): permite ver uma área na qual pode-se criar configurações especiais para o LDAP Server data source (patch: cluster_data > UME LDAP data);

UME (User Management Engine) Configuration iView: se a usage type EP Core for instalada no sistema SAP NW, pode usar o portal para ver a configuração da UME. (patch: System Administration > System Configuration > UME Configuration);

OBS: Para aplicar as alterações, reiniciar (restart) todas Java Instances. UME (User Management Engine) Parâmeters (págs 166 a 169) SAP recomenda que se use o Config Tool em modo offline (AS parado) para administrar os parâmetros (custer_Data > Server > cfg > Services > Propertysheet com.sap.security.core.ume.service). Proprieadades:

Security Policy: tamanho de senha, expiração, tamanho de login, etc.; E-mail Notification: ao criar/remover/bloquear usuário, etc. outras propriedades: histórico de alteração de usuário, criação de password

automático, imagem apresentada no login.

User and Group Administration Princípios do ambiente UME:

User: Propriedades gerais de um usuário (nome, email, etc); User account: Propriedades relacionadas ao Logon (pass, validade, etc); Group: configuração de user ou grupos; Role: Configuração de autorizações (Java);

Usuário associado a grupos que são associados a role, entretanto é possível associar roles diretamente a usuários. Grupos podem ter grupos subordinados e superordinados. A conexão entre a UME de um AS Java e User Management em um AS ABAP é estabelecido via JCO (Java Conector). O usuário de comunicação ABAP/Java é o SAPJSF, que contém a role SAP_BC_JSF_COMMUNICATION_RO (recomendada). A role pode ser alterada para SAP_BC_JSF_COMMUNICATION para ter direito de escrita. Administration Tools (pg 178)

Administration Console (baseado em Web Dynpro Java) Via URL: http(s)://<hostname>.<domain>:<http(s) port>/useradmin Via SAP NW Administration ( URL... /nwa) via the path System Management >

Administration > Identity Managment Em um portal via path: User Administration > Identity Managment

User Types Da mesma maneira que AS ABAP, a UME possue diferenças entre os tipos de usuários que são especificados quando criado um usuário via UME Administration Console.

User Type Logon AS Java

Pass Rules

Mapeado ABAP User Types (com ABAP System - Data Source)

Standard Possível Aplica Dialog

Technical users Possível Não aplica System

Internal service User Não possível Aplica -

Unknows Possível Aplica Communication, Service and Reference

Log and Traces Logs importantes no ambiente UME (User Management Engine) Security Log: Arquivo \usr\sap\<SID>\<instance number>\ j2ee\cluster\server<X>\log\system\security.<n>.log

Security Audit Log: parte do log de segurança (categoria System/Security/Audit) Trace Files: Arquivo \usr\sap\<SID>\<instance number>\ j2ee\cluster\server<X>\log\defaultTrace.<n>.trc

Directory Server Logs: Usar monitor LDAP server

The Java Authorization Concept J2EE security roles: administradas no Visual Administrator, parte do J2EE

Standard, e se refere a um objeto; UME roles: administradas via UME Console, uma extensão SAP que se refere à

vários objetos. (pág 192 a 197) * UME Roles podem somente ser administradas usando a UME Administration Console, e J2EE security roles somente usando o Visual Administrator. *

Special Principles (pg 204) Criados durante a instalação do AS Java para propósitos especiais enquanto outros são criados mais tarde pelo administrador. Default Users

USER

Data Source

Database

LDAP Server

ABAP System

Add-In -ABAP+Java

Remote

Administration User

Administrator Administrator J2EE_AD-MIN J2EE_AD-MIN_<SID>

Guest User Guest Guest J2EE_GUEST J2EE_GST_<SID>

Communic. User to data Source

SAP<SID>DB Freely Definable

SAPJSF SAPJSF_<SID>

Default Groups

Groups

Data Source

Database LDAP Server ABAP System

Administrators Administrators Administrators SAP_J2EE_AD-MIN

Guests Guests Guests SAP_J2EE_GUEST

All Users Everyone Everyone Everyone

Autehnticated Users

Autehnticated Users

Autehnticated Users

Autehnticated Users

Anonymous Users

Anonymous Users

Anonymous Users

Anonymous Users

Everyone: Cada user é sempre um membro do grupo; Autehnticated Users: Atribuir para todos users que tem que se autenticar no AS Java para este grupo; Anonymous Users: usuário que são capazes de fazer o logon anonimamente são atribuídas a este grupo Existe um usuário “emergencial” (SAP*) que pode ser desbloqueado em casos de necessidade. O desbloqueio é via Config Tool e todos os demais usuários ficam bloqueados quando este está desbloqueado. Necessário reinicializar o Java cluster.

Unit 4 - RFC Connections (pág 219) RFC Fundamentals RFC é uma tecnologia para conectar sistemas SAP. RFC entre servidores SAP permite processamento automático de dados. SAP GUI utiliza RFC para se comunicar com o sistema SAP. É um protocolo de interface SAP baseado em CPI-C. Uso de RFC:

Comunicação entre sistemas SAP ou SAP e sistema externo; Comunicação entre a aplicação SAP e o SAP GUI; Inicializar processos em paralelo no SAP.

Tipos de RFC: Synchronous (sRFC): comunicação entre sistemas diferentes e entre SAP Web AS e SAP GUI; Asynchronous (aRFC): comunicação entre diferentes sistemas e processamento paralelo; Transactional (tRFC): tipo especializado de aRFC, usado para comunicações seguras entre sistemas; Queued (qRFC): tipo especializado de tRFC, para comunicação em ordem específica. Transação SM59 cria novos destinos de RFC

Unit 5- Communication and Integration Technologies (pág 241) ALE (Application Link Enabling) possibilita a construção e a operação de aplicações distribuídas. Garante uma operação de distribuição integrada a um system landscape. Sistemas que usam ALE para troca de dados podem ser localizados na mesma empresa, ou pertencer a diferentes empresas. Característica: diferentes sistemas estão ligados em termos comerciais através de transferência de dados segura e consistente. Para aplicar ALE:

Identificar os processos de negócio e os objetos; Identificar informações a serem transmitidas; Especificar o formato de dados; Tipo de tecnologia usada; Tipo de transferência; Destino da transferência.

BAPI Bussines Application Programming Interfaces: interface que comunica com um objeto, através de métodos (ex.: alterar cadastro de algo). Transferência síncrona: na hora q acontece. Assíncrona: agendada. Remote Function Calls and BAPIs Sistemas SAP têm interfaces de comunicação em diferentes níveis. Opções de conexão usando o protocolo TCP/IP ou IPC-C, com interfaces altamente especializadas designadas para objetos de negócio, tais como BAPIs ou o IDOC utilizadas no ambiente ALE. Todas estas interfaces usam a mesma tecnologia, o Remote Function Call (RFC). RFC (remote function call): interface (não programa) executa funções em sistemas remotos ou no próprio sistema. Baseado no CPI-C e TCP/IP controla o processo de comunicação, parâmetros de transferência e controle de erros. Cada RFC é bidirecional, e programas externos também podem usar RFC para acessar funções em sistemas SAP. Transação SE37-Function Builder para criar parâmetros import/export. Para chamar um módulo RFC de um sistema SAP tem que conhecer estes parâmetros e deve haver uma conexão entre os dois sistemas, chamado RFC connection ou RFC destination.

Interfaces utilizadas por sistemas SAP

SM59: Gerenciar conexões de RFC. Quando você está definindo o destino de uma RFC, as conexões são endereçadas para um cliente e Acessadas de muitos clientes no sistema. Usuário do destino pode ser configurado na RFC, ou digitado no código que usa a RFC. Quando vários usuários usam uma RFC, é chamada Trusted RFC. BOR and BAPIs BAPIs estão definidos no BOR (Business Object Repository) como métodos de objetos de negócios SAP e permite uma visão OO dos dados comerciais no SAP. SWO1: Overview das BAPI’s disponíveis no BOR. BAPI: Acesso direto ao BOR.

Enterprise SOA (ESOA) (pág 256) Características:

Uma aplicação ESOA é geralmente implementada através de sistemas; Uma aplicação ESOA é criada em ABAP ou JAVA; Uma aplicação ESOA geralmente tem seu próprio DB; Novas funções são criadas nos sistemas existentes (para aplicações ESOA);

Web Service: serviço acessado via internet (protocolos) utilizando um web browser. Enterprise Service: conjunto de serviços que representam uma lógica de negócio. No SAP NW AS as seguintes normas básicas para WS são implementadas:

XML (eXtensible Markup Language); SOAP (Simple Object Access Protocol) - é um protocolo para chamar WS em

sistemas distribuídos de landscape. Utiliza HTTP como um protocolo de transporte;

WSDL (Web Service Description Language) - meta linguagem para descrever a função de um WS;

UDDI (Universal Description, Discovery, and Integration) é um diretório de serviço para WS dinâmicos; É fornecido via interface SOAP;

SAP Business Workflow. Eventos do workflow chamam BAPIs. Um evento de workflow cria um link entre uma atividade no sistema SAP e a pessoa envolvida.

Unit 6 - Working with SAP Solution Manager (pág 279) Concept of the SAP Solution Manager Plataforma de serviços e suporte para implementação e operação de sistemas SAP. Provê conteúdo, ferramentas e procedimentos para implementação, operação e suporte.

Para utilização desta plataforma central (SOLMAN), primeiramente deve-se manter os sistemas na sua solução de landscape utilizando a transação SMSY. Suporta durante o início do projeto, implementação funcional e técnica, durante o período em produção e durante a otimização dos landscapes. Centralizar no SolMan provê: distribuição e sincronização centralizada de customizações, gerenciamento de testes, monitoramento e gerenciamento de incidentes. Os processos de negócio do SOLMAN são mantidos centralizados no Solution Directory (transação SOLMAN_DIRECTORY) para que todas funções tenham acesso. Para monitoramento, podem ser criados Solution Landscapes, monitorado via Early Watch alerts (EWAs) ou via CCMS.

Funcionalidades: Serviços preventivos (Early Watch, GoingLive ...); Continuous Improvement services; Melhores práticas para sua aplicação SAP; Monitoramento da aplicação e do sistema; SAP Service Desk; Remote support (NetMeeting ...);

Para um overview da versão, estratégias e plataforma ver: (http://service.sap.com/solutionmanager → Release Strategy). SolMan fornece muitas funções para implementar e operar aplicações SAP. Suportes durante instalação:

Gerenciamento de projetos; Repositório de processos de negócio; Ferramentas para cenários integrados de negócio; Integrated Implementation Guides; Suporte ao monitoramento de processos de negócio; Monitoramento centralizado; Tarefas de administração centralizadas; Melhores práticas; Serviços remotos;

Monitoring with the SAP Solution Manager

Dados de monitoramento são coletados nos sistemas satélites através da RZ20 e SDCC, porém exibidos centralmente na RZ20 do SolMan. SolMan utiliza dados do CCMS e exibe em um contexto de negócio orientado a processos. Pode-se usar o Service Desk para controlar mensagens de problemas. Change request management:

gerencia todas as requests; classifica-as; aprovação de workflow; trace de status; documentação de alterações.

Mapping the System Landscape in SAP Solution Manager Para usar o SolMan em implementações e modelos de projetos, quando monitorar alterações de requisições, em sincronização de customizações deve-se criar e gerenciar localmente seus systems landscape existentes no SolMan. (fg 104 pg 291) Transação SMSY: Para definir um system landscape no SolMan. Fornece as seguintes funções:

Definição de produtos não SAP para posterior manutenção; Entrada de dados manual; Geração de RFC destino para os componentes de sistema;

Transação SPRO: Fornece informações sobre o procedimento de configuração do SAP SolMan. Pode-se distinguir entre configurações básicas e configurações scenario-specific. Para se trabalhar com SolMan, fazer primeiro todas configurações básicas antes das funções scenario-specific. Em um contexto SAP um Logical System corresponde para um client. Transação BD54: criar um Logical System Name. Transação SCC4: associa um Logical System para um client especial de um sistema SAP. SLD System Landscape Directory É um diretório Central com informações relevantes de todos os systems landscapes para gerenciamento do seu ciclo de vida. É um repositório que contém todas as informações dos produtos instalados (Ex: patchs, suport pack...). Estas informações são gravadas no DB (schema JAVA). Depois de instalado ele está disponível para cada sistema SAP baseado no AS Java, e deve ser configurado para uso. SLD simplifica o gerenciamento dos systems landscape e seu conteúdo é baseado no formato CIM (Common Information Model). O CIM standard é um schema geral para descrever elementos do system landscape. Chamada do SDL via: http://<sld-host>:<Port>/sld Ex: http:/<sld-host>:5$$00/sld Para o SLD receber automaticamente os dados enviados de sistemas SAP que forem conectados, deve-se iniciar e configurar um SLD bridge que converte dados que estiverem entrando dos dados fornecidos para um formato CIM compatível. Utiliza RFC para enviar dados de systemas ABAP e um Gateway deve ser configurado e o SLD bridge reiniciado (fig 110 pag 296). RZ20 configura conexões para o SLD bridge em ABAP. Programas com base em JAVA usam conexões HTTP para transferir informações para o SLD Server. Após a configuração na RZ20, dois Jobs são agendados: SAP_SLD_DATA_COLLECT executado periodicamente; SAP_SLD_DATA_COLLECT_STARTUP executado cada vez que o sistema é iniciado;

Estes jobs asseguram que as informações do SLD serão automaticamente atualizadas. Connecting SAP Solution Manager to the SLD (pg 298) Antes de usar o SolMan para gerenciar requests ou monitoramento central, todos sistemas (ex: DEV, QAS, PRD) devem ser mantidos na transação SMSY no SolMan. JCO (SAP Java Conector) é utilizado para transferência de dados entre sistemas SAP e SLD. Uma conexão RFC conecta SolMan com SLD (fig 113 pg 299 - RoadMap). Conectar o SLD para SolMan para usar SMD (SolMan Diagnostics) para monitorar sistema baseados em AS Java.

Creating a User to Communication with the SolMan com o SLD 1. Criar um usuário (SU01) associando a PFCG role SAP_SLD_CONFIGURATOR;

2. A PFCG role é mostrada como um grupo UME (User Management Engine); 3. Através do Visual Administrator, associar as security roles J2EE

LCrInstanceWriterLD e LCrInstanceWriterNR para o grupo UME SAP_SLD_CONFIGURATOR.

(Pág 302 a 336)

Unit 7 - System Monitoring and Troubleshooting AS ABAP (pg 337) Monitoring Architecture A infra-estrutura está instalada em todos componentes a partir de versões 4.x. Cada componente coleta seus dados e coloca na memória (monitoring segment). Recomendado ter um sistema independente para controle de transporte, CUA Central User Administration, monitoramento central, ou usar o SolMan para isso. O CCMS-Alert Monitoring Infrastructure é usado para um monitoramento eficiente para sistemas SAP. Consiste de:

data collection: coletores em cada programa, salva dados na memória; programas podem em ser ABAP, C ou Java;

data storage: onde ficam os monitoring segments; administration level (exibe e permite avaliação de dados).

Podem ser usados produtos de parceiros para o monitoramento, conectando no sistema através de interfaces.

RZ20 mostra o monitoramento em formato de árvore, cada nó é chamado de Monitoring Tree Element (MTE), e os valores são chamados de atributos (monitoring attributes). Monitor sets são diferentes por produtos. Os nós podem se repetir em várias árvores. Ajustando em uma, automaticamente são alteradas nas demais. Alguns monitores não exibem dados. Podem-se usar monitores padrões ou customizá-los.

Views Ao abrir o monitor (RZ20), duas visões são possíveis: Current Status: dados mais novos; Open Alerts: dados históricos. Including Remote Systems Os monitores fornecidos pela SAP exibem detalhes para a monitoração de dados locais para sistemas SAP. Central System Monitoring, por outro lado, tem a vantagem de que você pode controlar todos os sistems landscape, e não apenas o seu sistema local. Pode-se centralizar o monitoramento de todos componentes que possuem CCMS Monitoring Infrastructure. Para versões 3.x, usar programa SAPCM3X, para componentes não SAP SAPCCMSR. Criar 2 RFCs (tipo 3), para que uma acesse os dados do monitoramento (usuário communication), e outra para métodos de análise (current user). Sistemas SAP são incluídos na Central Monitorig System pela RZ21. Acessar RZ21, Technical Infrastructure > Configure Central System > Create Remote Monitoring Entry. Creating Your Own Monitors Why?

To display exactly the values that are important for your daily work Cross-system monitoring

How? What information do I need? Create own monitor set Create own static monitors Create own rule-based monitors (ADM106)

Tips: Create monitors for problems Transfer as little data as possible by RFC Monitor sets can be transported

SAP recomenda a criação de monitores customizados. Originais não podem ser alterados. Monitores devem conter poucos dados (por causa do RFC). Properties Variants and Threshold Values (pág 368) Threshold values determinam quando o status muda de cor (verde, amarelo, vermelho). Todos os sistemas possuem valores padrões, porém a SAP recomenda configurar no sistema central e transportar via TMS para outros sistemas (desde que estejam em properties variants). Properties variants são containers que guardam uma série de thresholds. Podem ser criados vários, mas apenas um estará ativo por vez. Vantagens:

pode ser alterado de um variant para outro para testes. pode ser linkado com o operation mode; pode ser transportado usando o TMS.

RZ21 > Properties > Variants.

Variants podem ser organizadas hierarquicamente, onde os valores não especificados são obtidos pelo “pai”, até chegar ao padrão (SAP-DEFAULT). Link com operation mode: RZ04 > Operation Mode > Change > Monitoring Properties Variant. Após criar uma variant, selecionar o atributo na RZ20 e ir em propriedades. Para copiar via TMS: RZ21 > Variant > Transport. Trace options SM21: System Log - detectar e corrigir erros de sistema e ambiente; ST22: Dump Analysis - erros em runtime geram um short dump (call program ABAP); ST01: System Trace - Grava atividades (authorization check, acesso DB, função Kernel, chamadas RFC..); ST05: Performance Trace - Grava chamadas acesso ao banco, lock management, remote cals…; ST11: Developer Traces - Informações sobre problemas internos;

System log - SM21 Local System Log: /usr/sap/<SID>/D*/log/SLOG Central System Log: /usr/sap/<SID>/SYS/global/SLOGJ Dump Analysis - ST22 Uma excessão não tratada gera um runtime error. Neste caso, o ABAP runtime finaliza a execução do programa, gerando um short dump. Situações de erros podem ser:

Internal Error: indentificado pelo error, contactar SAP; Installation and Enviroment/Resource Error: instalação incorreta ou recurso

faltando (ex.: shutdown); Error in Application Program.

Por default, short dumps são guardados por 14 dias. Short dumps podem ser removidos (goto > Reorganize) ou salvos sem limite de tempo (Short Dump > Keep/Release). SAP System Trace - ST01 (/usr/sap/<SID>/D*/log/TRACE) Primeiramente usado caso um authorization trace deve ser criado. SAP recomenda o uso de sytem log ou developer trace para analizar problemas. Usado para:

Authorization Checks: que permissões e quando são usadas; Kernel functions; - Kernel Modules; DB Accesses (SQL Trace): quando e com que parâmetros as Open SQL são

transformandas em comandos SQL; Table buffers; Lock operations. Exibe quando chamadas RFCs são feitas e na instância que

são executadas. Performance Trace - ST05 (/usr/sap/<SID>/D*/log/TRACE)

Gravar chamadas ao banco; gravar gerenciamento de lock; buffers de tabelas; remote calls de reports e transações; análize detalhada de trace records; análize de comandos SQL.

Os traces não são escritos diretamente em arquivos, mas guardados antes em um buffer. O parâmetro rstr/buffer_size_kB determina o tamanho deste buffer. O arquivo de buffer é criado com nome de acordo com o parâmetro rstr/filename; O arquivo de trace cresce até o tamanho de rstr/max_filesize_MB e então os mais antigos são renomeados, adicionando 00 até 99, ou quantidade definida pelo parâmetro rstr/max_files. OSB: Transação RSPFPAR Developer Trace - ST11 (/usr/sap/<SID>/D*/work/dev_*) Contém informações técnicas e é usado em caso de erros. Utilizado para investigar problemas no SAP e servidor. O Acesso pode ser feito via SO, AL11 ou SM50 (Process >Trace > Display File).

Unit 8 - Monitoring AS Java Java Monitoring: Overview Junto com o CCMS, SAP NW AS Java fornece uma arquitetura de monitoramento que acumula dados, históricos e gera alertas. Podem ser exibidos localmente ou em um monitoramento central, usando o agente SPCCMSR.

Funções para monitorar AS Java:

Monitoring Service; Logging usando o Log Viewer; Application Trace; Single Activity Trace; System Info; SAP Application Statistics

Monitoring Service - Consiste de monitores de status e de configuração. Arquitetura baseada no padrão JMX. Monitora memória, threads, serviços e managers, conexão com o BD, transações do BD e sessões. Visualizado no Monitoring Service do dispatcher e do Server, via Visual Administrator. Logging - Todos eventos importantes são gravados em log. Configuração via Log Configurator Service e exibido via Log Viewer. Application Trace - Usado por desenvolvedores para Debug. Alguns marcadores mostram o tempo usado por métodos. Application Trace é integrado no Performance Tracing service no Visual Administrator. Para ativar o trace ST05 (http://<host>:5$$00/SQLTrace) Single Activity Trace (SAT) - Faz trace de requisições individuiais, que rodam em vários components. Faz parte do Performance Tracing service no Visual Administrator e visto via Log Viewer. SAP Application Statistics - Se existem problemas de performance, cada usuário individual pode ser adicionado na análise. Coleta tempo de resposta da aplicação, usuário que criou a requisição e a quantidade de dados transferidos. Visualizado no Visual Administrator, no Performance Tracing service. SQL Trace - Trace de SQL pode ser ativado dinamicamente, e aponta o SQL, tempo, duração, resultados e parâmetros utilizados. System Info - Mostra o status dos dispatchers, servidores, service pack...

Integrating the SAP Web AS Java Monitoring Data into a Central Monitoring System (pág 403) É possível monitorar o SAP NW AS Java de uma central de monitoramento ABAP usando a arquitetura de monitoração CCMS. Os dados coletados pelo JMX podem ser enviados ao CCMS do sistema central via agente SAPCCMSR. Dados apresentados no central Monitoring do NW AS Java:

Dados de monitoramento; Dados de disponibilidade; Dados estatísticos: ST03G: dados estatísticos relacionados à performance. AS

Java usa distributed statistic records (DSRs). Para ativar, registrar o agente SAPCCMSR e agendar o job SAP_COLLETOR_FOR_NONE_R3_STAT. Transação STATTRACE: trace de performance.

Monitoramento de logs: monitora warnings, errors e fatal e dispara alertas. Resultados exibidos na RZ20.

Monitoramento do sistema operacional (coletados via SAPOSCOL e transferido via agente);

Monitoring SAP NW AS Java O monitoramento é basedo no Java Management Extension (JMX). Através da API JMX é possível monitorar os recursos de todos componentes do servidor e de aplicações usando MBean (Manageable Bean).

Tarefas da interface JMX e do Monitoring Service: Monitorar o status atual; Criar histórico; Usar mecanismo de alertas para reagir em situações críticas; A infraestrutura JMX é provida pelo JMX Adapter Service. Os dados são coletados dos monitores JMX (passivo) ou os recursos mandam dados (ativo). JMX usa configurações em arquivos XMLs, e a SAP provê templates para serem usados. SAP recomenda monitoramento do Java via CCMS (ABAP) no PRD. Lá podem ser configurados sistemas de notificação e de auto-reação.

The Monitoring Tree in SAP NW AS Java Visual Administrator > Server > Services > Monitoring:

A estrutura da árvore contém:

Kernel; Performance; Services; System: propriedades do sistema; Applications: desenvolvedor utiliza funções no código, para monitoramento.

Table buffer é exibido aqui, por default. History - Contém os mais recentes valores coletados de cada monitor, sendo exibidos também por hora. Um threshold value quando o alerta (cores do monitor) devem ser disparados.A freqüência de coleta de dados pode ser alterada em Configuration > General (do monitor).

Connecting to a Central Monitoring System (pg 433) No SAP NW AS Java, existe uma infraestrutura de monitoramento que coleta vários dados e disponibiliza no Visual Administrator. Os dados podem ser exibidos na CCMS usando o agente SAPCCMSR. Connecting to a Central SAP ABAP Monitoring System

Se o SAP NW AS Java é iniciado, os monitores JMX são criados. Durante a instalação o agente SAPCCMSR cria um segmento na shared memory separado, onde os dados de monitoramento do AS Java são guardados. O agente manda dados para o CMS via RFC a cada 60 segundos. Data Transfer Using the SAPCCMSR Agent

Para instalar e configurar o agente SAPCCMSR:

criar o usuário CSMREG no CMS (RZ21); criar arquivo CSMCONF no CMS (RZ21); registrar o agente com o SAP NetWeaver CCMS Agent Setup Tool;

O arquivo CSMCONF é guardado no diretório do SAPCCMSR (/usr/sap/ccms/<SID>/sapccmsr). Este arquivo contém informações do usuário CSMREG e do administrador do ambiente.

O agente SAPCCMSR é registrado com o Visual Administration. Ele é iniciado automaticamente no script startsap no UNIX. No Windows o agente é criado como um serviço durante a instalação. Visualizar os dados de monitoração do J2EE no Alert Monitor (RZ20), para isso, selecionar o monitor SAP J2EE Monitor Templates. Dados armazenados:

Engines monitor: kernel, memória, serviços, performance... Applications monitor: dados de aplicações.

Log Viewer and Log Configuration (pg 447) Todos Java nodes gravam logs e traces em arquivos do SO. Para cada node, (Java Dispatcher e Java Server) os arquivos são gravados em diretórios separados nomeados “log” no SO. Java Servers possue mais arquivos de logs que Java Dispatcher Diferentes tipos de arquivos de log: Logging Means e Tracing Means. The Log Viewer Todos os componentes java usam a mesma infraestrutura de log e trace, o que permite visualização central dos logs (Log Viewer). O log viewer é usado para ver arquivos de logs, independente de quem gerou (kernel, services, etc.). Pode ser usado para pesquisa de índice de severidade nos logs. Log Viewer pode ser usado com as seguintes variantes:

como Log Viewer no SAP NW Administrator; como um integrado log viewer (Visual Administrator); como um central log viewer: visualização central de logs (de outros servers); log viewer via linha de comando.

Log Viewer Integrado Log Viewer roda como serviço no AS Java, disponível via Visual Administrator. Log Viewer é usado inicialmente para ler e para registrar arquivos de log. Cada aplicação fornece o log-configuration.xml, que é registrado manualmente ou automaticamente (diretório de logs ou via conexão de soquete). O registro de logs pode ser feito de forma manual (Log Viewer Service > Runtime > Add file) ou via log directory (importa do diretório tmp). The Central Log Viewer

Permite visualização de logs mesmo quando o AS Java não está ativo, e visualização de logs ASCII, como do banco de dados. Central log viewer consiste do Log viewer e um adicional servidor remoto. Conecta no NW AS Java via porta P4 e no servidor remoto via porta RMI. Scritps para o Log Viewer central estão dentro de admin/logviewer_standalone. O remote server é iniciado por um script remoteserver.bat/remoteserver.sh em cada AS a ser monitorado, e o logviewer.bat no que exibirá o log. File > Connection to server para adicionar servidores a serem monitorados. Necessário registrar os logs para exibição. Logging and Tracing (pg 459) Arquivos de log são mostrados no Log Viewer. Dois tipos: arquivos para logging e arquivos para tracing. Logging Means (significado):

eventos normais e excepcionais; informações de runtime de uma aplicação ou sistema; atividades durante operação normal; dividido em categorias: sistema, aplicação e performance que apontam para

um ou mais logs. Tracing Means (significado):

fluxo de processos de uma aplicação; usado no desenvolvimento e para detecção de erros em produção; todos os traces são guardados no trace default; são estruturados em locations, que representam códigos de áreas, como

classes ou packages. Logging/trace infraestructure consiste de:

SAP Logging API, Log Manager, Log Controller; é configurado usando o Log Configurator Service; é apresentado no Log Viewer.

O Log manager lê o arquivo de configuração e informa ao Log Controller qual nível de log deve ser capturado. Este por sua vez cria o output dos dados de trace. Os arquivos de logs são salvos em <j2ee>/cluster/<server ou cluster>/log. Existem 7 níveis de log, sendo 3 para trace (ALL, DEBUG, PATH) e 4 para log (INFO, WARNING, ERROR, FATAL). O Log Configurator Service fornece um ambiente para configuração de logs e traces. Use o log configurator via visual administrator para:

mudar o nível do trace; adicionar, mudar ou remover destinos de logs; adicionar, mudar ou remover formatos de log (diferentes de XML, como traces); adicionar, mudar ou remover controladores de log; arquivar arquivos de log.

Log Formaters cuidam do tipo de formato de log (XML, trace, etc.), log destination é onde ficam guardados e log controllers são os objetos que podem escrever logs/traces. A mudança do nível de log pode ser feita via controllers (principal) ou no destino do log. Os logs são automaticamente (por default) arquivados em <j2ee>/cluster/<server ou cluster>/log/archive. Não são apagados automaticamente. O Log Configuration Tool é usado quando o AS não está disponível, e pode ser feito download a partir do SDN. Via Log Manager é possível configurar o destino do log, se vai ser junto com os outros (padrão) ou separado.

Availability Monitoring (pg 478) Ferramentas disponibilizadas para monitorar aplicações e o AS são baseadas no GRMG (Generic Request and Message Generator). GRMG é separado em duas partes: Infraestructure: parte da arquitetura de monitoramento do CCMS. Manda um XML para a aplicação GRMG, recupera a resposta e encaminha-a para o CCMS; Application: interface JSP ou BSP para monitoramento de disponibilidade. O monitoramento é conceituado como agente, sendo executado separadamente da aplicação monitorada.

Cenários:

customização técnica para monitoramento: aplicação já existente, onde será habilitado o monitoramento;

instrumentação da aplicação: criar na aplicação um monitoramento GRMG. GRMG usa funções do CCMS Monitoring Infrastructure para armazenar informações do heartbeat Herbeat: Um sinal é enviado pelo software em intervalos regulares para comunicar a disponibilidade; GRMG infrastructure manda XML para GRMG application > GRMG application faz testes de disponibilidade e manda de volta para o GRMG infrastructure > GRMG infrastructure manda resultado para o Alert Monitor. Para configurar monitor de disponibilidade:

alterar o grmg-customizing.xml via Visual Administrator; upload do arquivo no CMS (automaticamente via SAPCCMSR ou manualmente

via transação GRMG); Iniciar cenários GRMG para monitoramento de disponibilidade.

Para criar um monitoramento GRMG na aplicação:

Desenhar o cenário GRMG (aplicações, componentes, processos, etc.); Criar mensagens que serão retornadas; Criar um template do arquivo de customização; Implementar a aplicação.