Academia Basis - Semana 1

Academia Basis

Semana 1 – 26/01/2000 a 28/01/2000 (Vera)José Roberto A. de Lima – SAP Brasil

Índice

ACADEMIA BASIS 1

Semana 1 – 26/01/2000 a 28/01/2000 (Vera) 1

Índice 2

BASIS SYSTEM AND THE SYSTEM ENVIRONMENT 4

The Integration Model 4

Business Framework Architecture 4

R/3 as an Open System 5

Scalability and the Client/Server Concept 5

The Middleware Basis 6

Portability and System Plataforms for the R/3 System 7

NAVIGATION 8

Logging onto R/3 System 8

R/3 Menu Structure 8

SYSTEM KERNEL 10

R/3 Presentation Interface 10

R/3 Database Interface 10

Work Processes and Dispatcher 10

R/3 Application Services 11

R/3 Transaction and LUW 12

Lock Concept and Asynchronous Update 13

Background Processing 14

R/3 Printer Services 15

R/3 Instance 15

INTERFACES 16

R/3 as an Open System 16

R/3 Gateway Service 16

Communication with CPI-C 16

Remote Function Call 17

Business Objects and BAPIs 18

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

Internet Architecture 19

EDI Architecture 19

Distribution of Business Processes with ALE 19

Data Transfer and Batch Input 20

R/3 GRAPHICAL USER INTERFACE 20

Frontend Administration 20

Frontend Requirements 20

SAPGUI Installation 21

Types of Online Help 21

SAPLOGON 22

SAP MAPI 23

SAP ONLINE SERVICE SYSTEM (OSS) 23

OSS Overview 23

OSS Functionality 23

OSS Access 23

SAPNet 24

SAP TechNet 24

Basis System and the System Environment

The Integration Model

O Sistema R/3 é composto dos seguintes módulos:LogísticaSD – Sales & DistributionMM – Materials ManagementPP – Production PlaningQM – Quality ManagementPM – Plant Maintenance

Human ResourcesHR – Human Resources

AccountingFI – Financial AccountingCO – ControllingTR – TreasuryPS – Project System

Industry and Cross-ApplicationWF – WorkflowIS – Industry Solutions

A camada Basis integra todos estes módulos. É a parte central do “diamante” do diagrama do R/3

Business Framework Architecture

Business Framework Architecture (BFA) é a arquitetura estratégica do produto R/3. Ela trabalha com business components que são os módulos funcionais (FI, CO, etc.) configuráveis para se adaptar a cada empresa.

Esta arquitetura fornece agilidade para se adaptar a um novo negócio, além da facilidade de se integrar com pacotes externos e fácil integração com a internet e intranet, permitindo desta forma uma fácil evolução sem a interrupção da operação do negócio da empresa.

O Business Framework se mostra no R/3 como uma família de componentes separados porém integrados entre si. Estes componentes são: Business Components: são os módulos funcionais (FI, CO, etc.) Business Objects: Ordem, Empregado, Material, etc.

Academia Basis – Semana 1 - 26/01 a 28/01/2000 Pag. 4José Roberto A. de Lima – SAP Brasil

BAPI Interfaces: São os métodos com que os objetos de negócio são implementados dentro do R/3 (criar uma ordem, alterar o endereço de um empregado, etc.)

R/3 as an Open System

O R/3 utiliza protocolos standard da industria para garantir a integração com outras aplicações: TCP/IP: é o protocolo de comunicação EDI: Electronic Data Interchange, é o mecanismo utilizado para trocar informações

de negócio com diferentes sistemas OLE: Object Linking and Embendding, integra aplicações PC com o R/3 Open Interfaces, tais como arquivamento ótico, dispositivos de códigos de barras,

etc.

Além de standards da indústria, o R/3 também utiliza protocolos proprietários para comunicação: RFC: Remote Function Call, que utiliza o protocolo CPI-C standard da IBM para

comunicação e processamento das aplicações e tasks dentro do sistema R/3 ou com o sistema R/2 ou outros sistemas.

ALE: Application Link Enabling permite o processamento distribuído dentro do R/3

Scalability and the Client/Server Concept

O R/3 permite a sua implementação quer seja em uma configuração centralizada quer seja em uma arquitetura totalmente distribuída client/server em vários servidores dedicados.

Esta arquitetura permite que se separe a lógica da aplicação da base de dados e da camada de apresentação. Esta configuração permite ainda otimizar os custos e distribuir a carga através de configurações variadas de hardware. Com isto é possível dimensionar os servidores de acordo com a carga, permitindo a fácil escalabilidade do ambiente.

Os ganhos nesta arquitetura na implementação R/3 são muitos: Simples instalação de novos servidores para atender gargalos Servidores trabalham em paralelo, com carga homogênea e execução local dos

programas. Baixo tráfego de rede com a localização dos buffers de dados e programas próximo

de onde serão utilizados Balanceamento de carga, seja para o processamento online (logon) seja para o

processamento batch

Na implementação R/3, a arquitetura clint/server é orientada para o software, e não para o hardware como estamos acostumados a ver. Desta forma, Client é quem requisita e utiliza o serviço e Server é quem vai fornecer determinado serviço.

Um servidor de aplicação por exemplo é server de alguns serviços das estações clients, porém é client dos serviços fornecidos pelo servidor de banco de dados.


Os serviços (ou camadas) fundamentais de uma aplicação são três: Presentation, Application e Database services.

Existem várias formas de se implementar um sistema R/3: Central, onde todos os componentes estão implementados em um mesmo host. Esta

implementação corresponde a clássica implementação mainframe. Two-tier, onde uma camada normalmente executa as funções de presentation

(usualmente um PC) e a outra camada executa os serviços de application e database. Uma outra implementação two-tier poderia ser uma camada executando os serviços de database e a outra composta por PCs mais potentes que executariam as funções de presentation e application. Esta última implementação é normalmente utilizada em simulações ou desenvolvimento de software.

Three-tier, onde cada serviço tem o seu próprio host. Nesta configuração é possível ainda assegurar uma divisão de carga na camada de aplicação, garantindo que determinados hosts fiquem dedicados para aplicações específicas. Por exemplo dedicar um host para servidor de aplicação dos usuários de MM, ganhando com isto performance na distribuição dos serviços.

A configuração three-tier é a mais recomendada em R/3 por garantir a melhor distribuição de carga e escalabilidade nos grandes sistemas

Todos os servidores em uma configuração R/3 devem possuir endereço de IP fixo

Um sistema R/3 agrupa todos os componentes que estão associados com um banco de dados. Se utilizamos uma implementação em 3 camadas, os componentes do R/3 estarão presentes em todas as camadas da hierarquia: O Database Server, é instalado em um host central, onde todos os serviços de

bancos de dados serão executados. Um ou mais Application Servers conectados ao servidos de banco de dados.

Nestes servidores estarão sendo processados a lógica da aplicação, ou seja, os programas.

Vários Presentation Servers conectados aos servidores de aplicação. Estas máquinas são também chamadas de frontends ou workstations. Nestas máquinas os usuários irão interagir com o sistema R/3 utilizando uma interface que proverá os serviços de presentation.

The Middleware Basis

O software Basis do R/3 (também chamado de middleware) roda em diferentes plataformas e também pode ser adaptado para atender as necessidades individuais das empresas. São vários os serviços que ele presta: Provê o ambiente de runtime para as aplicações R/3 Cuida da perfeita interação das aplicações com o sistema Define uma arquitetura estável para as melhorias do sistema Contem todas as ferramentas necessárias para a administração do ambiente Permite a distribuição equitativa dos recursos e componentes do sistema Provê as interfaces necessárias para os sistemas descentralizados e os produtos

externos ao R/3


As principais características da tecnologia Basis são: É uma arquitetura voltada para a configuração client/server Trabalha com bancos de dados relacionais Possui interface gráfica com o usuário (GUI)

O Basis é o responsável ainda pela integração dos aplicativos e do ABAP workbench com o software básico.

Portability and System Plataforms for the R/3 System

Para garantir uma alta portabilidade, as interfaces com o software básico são divididas em suas próprias camadas que variam de sistema para sistema (NT ou UNIX, Oracle ou Informix, etc.). Acima destas camadas as funcionalidades dos componentes R/3 são basicamente as mesmas, independentemente do hardware, software ou sistema operacional.

A System Interface é responsável pelo interfaceamento do R/3 com as diversas plataformas em que ele pode ser implementado.

O Flow Control fica logo acima das interfaces com o software básico (System Interfaces). Ele é o responsável por tarefas tipo scheduling ou gerenciamento de memória, tarefas estas muito próximas ainda do sistema operacional e que são parcialmente efetuadas por ele, mas são gerenciadas pelo R/3 por razões de portabilidade e performance.

A User Interface provê as opções de apresentação dos aplicativos

A Communication Interface é o canal para a troca de informações, seja pela transferência de dados com o legado, seja pela comunicação program-to-program provida pelo protocolo CPI-C ou ainda através da troca de informações pelo protocolo EDI.

Todos os programas no R/3 são escritos na linguagem ABAP, proprietária do sistema. O DYNPRO é o screen interpreter e o sistema possui ainda um ABAP interpreter. A interação entre estes dois componentes forma a tecnologia Basis das aplicações R/3. O funcionamento destes dois interpretadores (tela e programa) se baseia em informações armazenadas no dicionário do sistema, o ABAP Dictionary.

O R/3 roda nos mais diversos hardwares, sejam plataformas Intel, Risc ou Unix Systems

Os sistemas operacionais são também os mais diversos, de acordo com as plataformas utilizadas (AIX, Solaris, HP-UX, Windows NT, OS/400,etc.)

Os bancos de dados utilizados pelo R/3, todos relacionais são: Oracle, Informix, MS SQL Server ou ainda o DB2 para as diversas plataformas.

O SAPGUI que faz a camada de apresentação possui versões para Windows (3.1, 95, NT), OS/2 e Java

As linguagens utilizadas no R/3 são ABAP, C, C++, HTML e Java


Navigation

Logging onto R/3 System

O R/3 é um sistema voltado para clients. Com este conceito é possível controlar várias empresas em único sistema, separando-as por client (ou mandante)

As chaves para se logar no sistema também são separadas por client. Para efetuar um logon é preciso ter chave no client específico.

Além disso o sistema exige uma password e por ser multilingua, deve-se ainda especificar a lingua desejada no momento do logon.

Um client pode ser visto como uma entidade organizacional separada dentro do R/3, com seus próprios dados (master data, transaction data), user master records e parâmetros específicos de customização.

Apesar dos dados serem armazanados em tabelas únicas, os dados dos diferentes clients coexistem separados pela diferenciação do campo MANDANT que faz parte da chave da maioria das tabelas (client dependents).

O conceito de customização é a adaptação do sistema R/3 para as necessidades específicas de um usuário.

Ao instalar um sistema R/3, ele vem basicamente com 3 clients default: 000 é definido como um SAP standard é não deverá ser alterado pelos clientes,

devendo ser utilizado como um template para a criação de novos clients 001 066 utilizado pela SAP para se logar no ambiente do usuário para a execução de

determinadas tarefas

Um client é identificado pelos três dígitos numéricos e, com exceção dos 3 citados acima, cada instalação pode definir quantos clients se desejar (ou a sua base de dados suportar)

R/3 Menu Structure

Uma vez logado no sistema R/3 o sistema exibe um menu principal, onde temos as principais áreas do R/3 (Logistic, Accounting, Human Resources) entre outras entradas. Ao se escolher uma determinada entrada o sistema exibe um menu pull-down com opções de cascading em algumas entradas.

As opções System e Help são comuns a todas as telas do sistema

Um nível abaixo fica o menu específico de cada aplicação, que exibe as funções básicas disponíveis para aquele sistema (criar um registro, por exemplo)

O Dynamic Menu disponível na tela inicial dá a opção de navegar em todas as opções disponíveis no formato de árvore do explorer, podendo selecionar a função desejada. É uma ferramenta que permite efetuar searchs por palavras chave


Uma tela típica do sistema R/3 possui as seguintes partes: Title Bar, exibe o título da task que está sendo executada Command Field, onde se pode escolher uma task diretamente sem a necessidade de

navegar no menu Options, o mickey, onde se pode configurar a interface SAPGUI de acordo com

necessidades individuais dos usuários Standard Toolbar, onde se encontram os ícones mais frequentemente usados para

navegação no sistema, bem como ícones para salvar dados e ativar o online help Checkboxes, Radio buttons, Text boxes e outras interfaces comuns no ambiente

windows para a exibição de dados Status bar, exibe informações referentes ao status atual do sistema (session

number, system name, application server, worksation’s time, além de mensagens de interação com o usuário.

Text box inicializados com interrogação (?) são de preenchimento obrigatório

Uma tela no R/3 pode ser acessada de 3 maneiras distintas: Selecionando a opção no menu Através de teclas de atalho (ALT + tecla) Através do código da transação diretamente digitado no command field

O command field aceita vários comandos que funcionam em conjunto com o código da transação /n para encerrar a transação atual /o para abrir uma nova sessão /i para encerrar a sessão corrente /nend e /nex para efetuar logoff no sistema com e sem prompt, respectivamente

A tecla F1 ativa o help de campos, menus, funções e mensagens

O help também exibe informações técnicas referentes aos campos de uma tela, como por exemplo o parameter ID do campo que pode ser utilizado para customizar a tela com parâmetros default do usuário. (F1 + F9 também exibe as technical infos)

A tecla F4 exibe os valores possíveis em um campo, onde esta informação está disponível (combo boxes)

A opção System do menu é utilizada para exibir as tarefas comuns aos usuários do R/3

A opção User profile Own Data do menu System permite ao usuário especificar valores defaults para seus campos, baseado no ID do campo (ver technical info)

Na opção System é possível ainda configurar a lista de favoritos de cada usuário (User Profile Favorite maint)

O Session Manager é uma ferramenta que permite ao usuário gerenciar todo o ambiente e até mesmo vários sistemas de uma única interface. No release 4.0 esta ferramenta ainda não se encontra em um estágio muito útil, mas cresceu muito no release 4.6


System Kernel

R/3 Presentation Interface

A interface de apresentação do R/3 é o SAPGUI que apresenta uma funcionalidade muito parecida entre as diversas plataformas do R/3. Um usuário treinado em uma determinada plataforma, salvo pequenas exceções está apto a operar o sistema nas suas mais diversas implementações

O fluxo de informação entre o SAPGUI e o servidor de aplicação não consiste de telas preformatadas, mas sim de strings lógicos contendo dados e caracteres de controle, o que faz com que o tráfego de dados se mantenha na casa de 1 a 2K por tela (cada enter)

R/3 Database Interface

O R/3 trabalha com bases de dados relacionais, que são compostas de tabelas bidimensionais e interagem com os sistemas através da linguagem padronizada SQL (Structured Query Language) que é comum a todas as implementações de bases relacionais, embora cada fabricante implemente algumas extensões no seu produto.

O DB Interface é um módulo dentro do R/3 que converte os comandos SQL codificados nos programas ABAP para o SQL nativo do banco implementado em cada ambiente R/3. Ou seja, cada implementação (Oracle, Informix, SQL Server) possui um módulo de DB Interface particular para aquela implementação, o que torna os programas ABAP independentes da implementação do banco.

Estes comandos SQL escritos no ABAP são denominados OPEN SQL e o DB Interface é responsável pela sua correta transcrição para o SQL nativo do banco. Além disso, um programa ABAP pode codificar o comando diretamente em Native SQL. Neste caso o comando não passará pelo DB Interface, indo diretamente para a DB machine. Estes comandos poderão não ser independentes do banco utilizado, se utilizarem extensões particulares de um determinado RDBMS.

Os comandos SQL escritos em OPEN SQL tem sua sintaxe verificada pelo DB Interface que inicialmente faz um acesso no buffer interno do application server para evitar acessos desnecessários ao DB server. Comandos escritos em native SQL não fazem uso deste buffer interno, uma vez que o acesso não passa pelo DB Interface.

Work Processes and Dispatcher

Os principais componentes de um application server são: Um dispatcher como o controle central da instance Dispatcher queues para enfileirar as requisições (FIFO) Um número configurável de work processes para processar os programas ABAP Buffers e shared memory

Os work processes são serviços dentro de um sistema R/3 especializados em determinadas tarefas.


O centro de um sistema R/3, a nível de controle de aplicação, é o Dispatcher. Ele, juntamente com o sistema operacional, é o responsável pelo controle e disponibilização dos recursos do sistema.

Suas principais tarefas são o controle da comunicação, a conexão com o presentation e a distribuição de carga entre os work processes.

O dispatcher distribui os serviços requisitados entre os WP disponíveis e se encarrega de enviar o dado processado para o SAPGUI, que deverá interpreta-lo e exibir para o usuário.

Não existe um WP fixo para um determinado usuário, cuidando o dispatcher de ir utilizando-os conforme as requisições vão chegando, em um processo de fila FIFO

Quando um sistema R/3 é inicializado, o dispatcher é o responsável por ler os parâmetros de configuração (profiles), gerar as rol areas, inicializar os work processes e se conectar com o message server da central instance.

Cada dialog work process é coordenado por um componente interno denominado Task Handler. Ele ativa o screen processor ou o ABAP processor e é ainda o responsável pelo roll in e rool out das áreas de usuário.

Existem memórias de uso exclusivo de um determinado work process e memórias que podem ser compartilhadas por todos eles. Esta diferenciação é gerenciada pelo memory management. A memória utilizada exclusivamente por um work process possui duas áreas reservadas para dados específicos de uma determinada sessão de usuário (user context area) e devem ser mantidas entre as pseudo conversas do dialog. Estas áreas são denominadas roll e paging areas. A roll area contem dados que ficam imediatamente disponível para o processamento no início do dialog step (roll in) e é salva novamente no final do dialog step (roll out).

Este mecanismo de roll in e roll out é que permite o share dos work process permitindo o compartilhamento do recurso entre todos os usuários. Nesta área são salvos os dados referentes ao usuário (user context) tais como suas autorizações, informações administrativas além de dados adicionais para o ABAP e dialog processors, que são dados que já foram coletados por dialog steps anteriores.

Na shared memory existem dados disponíveis para todos os work processes, tais como o calendar, screen, table e program buffers.

R/3 Application Services

Um sistema R/3 é composto de uma série de work processes que funcionam em paralelo cooperativamente. Cada application server possui um dispatcher e um número configurável destes processos, que depende dos recursos disponíveis no host (basicamente memória e processamento). Work processes podem ser instalados para efetuar serviços de dialog, update, backgrond e spool

Uma central instance possui ainda serviços de enqueue para gerenciamento de lock e dois outros serviços próprios:


O Message Server responsável pelo serviço de comunicação entre os vários dispatchers que compõem um sistema R/3, que é portanto um pré requisito para a escalabilidade de vários servidores de aplicação trabalhando em paralelo.

O Gateway Server, também chamado de CPI-C handler, que permite a comunicação entre R/3, R/2 e aplicativos externos.

R/3 Transaction and LUW

Transações são unidades de processamento agrupadas em funções que executam alterações consistentes na base de dados, de acordo com a funcionalidade a que se propõem. Um exemplo típico seria o débito em uma conta para crédito em outra, que somente fazem sentido consistente quando executadas como um todo.

Uma transação SAP é implementada através de uma série de dialog steps consistentes e conectados de forma coerente.

Uma transação SAP não executa necessariamente em um único work process, uma vez que cada um dos seus dialog steps poderão estar sendo atendidos por WP diferentes que o dispatcher encontrou disponível em cada momento. Além disso, quando se utiliza o asynchronous update para processar as atualizações da base de dados, estes processos estarão sendo atendidos por outros work process que poderão inclusive se encontrar em outros hosts.

No R/3 cada dialog step é composto de um processamento que inicia após o usuário entrar o dado (PAI – Process After Input) e pelo processamento e envio da próxima tela (PBO – Process Before Output).

Do ponto de vista do usuário, cada dialog step começa com o preenchimento de uma tela e o posterior processamento até o envio da próxima tela. Para o sistema apenas as partes referentes ao processamento (PAI e PBO) compõem o dialog step já que durante o preenchimento da tela nenhum processamento será requerido.

Este conceito de transação, que pode compor de um ou vários dialog steps, é chamado de LUW, ou Logical Unit od Work.

Como os bancos de dados não suportam o conceito de transação para todos os processos (begin/end transaction commands), é necessário saber diferenciar uma transação do ponto de vista SAP (SAP-LUW) de uma transação de banco de dados (DB-LUW) que é totalmente executada ou totalmente desfeita. Não existe meio termo numa DB-LUW.

Enquanto uma SAP-LUW garante a integridade lógica do banco de dados (um determinado lançamento deverá existir nas tabelas x, y e z), uma DB-LUW garante a integridade física do DB e é executado necessariamente pelo gerenciador do banco.

Uma transação SAP inicia uma SAP-LUW que somente termina ao encontrar um comando COMMIT WORK no programa ABAP ou então no final do asynchronous update.


Lock Concept and Asynchronous Update

A técnica principal utilizada numa SAP-LUW é a atualização assíncrona, onde as requisições de update na base de dados são coletadas separadamente e iniciam após o COMMIT WORK, onde são executadas em uma única DB-LUW para garantir a integridade do banco.

Os mecanismos de lock existentes nos gerenciadores de bancos de dados não são suficientes para garantir a correta manipulação dos objetos de negócio, que muitas vezes envolvem uma série de tabelas em um único lançamento. Com o seu próprio mecanismo, O R/3 assegura que determinados dados permaneçam protegidos durante todo o processo de atualização do objeto.

Esta tarefa é executada pelo Enqueue Work Process que utiliza uma tabela armazenada na memória principal (de onde o enqueue work process está rodando, normalmente a central instance) para este gerenciamento.

Sempre que um lock é requisitado o sistema verifica (através do enqueue wp) se a requisição não fere outro lock já postado na tabela. Havendo colisão de interesses, o processo é informado através de uma mensagem de erro, o que permite ao programa ABAP informar ao usuário que a sua operação não poderá ser executada no momento.

Caso o enqueue work process não se encontre na mesma instance em que o processo está correndo, o que é normal em uma aplicação three-tiers, esta comunicação é efetuada pelo message server.

Para que este mecanismo de requisição de lock funcione no sistema R/3, é necessário que um objeto de lock seja definido no dicionário ABAP especificamente para aquele objeto que se deseja travar.

Já existem objetos definidos em uma tabela primária no dicionário do R/3, porém o usuário pode definir seus próprios objetos em tabelas secundárias (estes objetos do usuário precisam ter seus nomes começados por “EY” ou “EZ”.

Os locks podem ser do tipo “S” (read) ou “E” (write). Um lock do tipo E somente poderá ser postado se não existe nenhum outro lock já definido sobre o registro.

Quando um objeto de lock é ativado, o sistema gera duas funcion modules, uma para ENQUEUE_<object> e outra para DEQUEUE_<object>

Os lock postados por um programa permanecem até que sejam retirados pelo próprio programa ou ainda pelo procedimento de update (segunda parte da SAP-LUW).

Work processes podem gerar atualizações diretamente na base de dados mesmo que o banco não se encontre no mesmo host.

Quando o programa ABAP utiliza os comandos CALL FUNCTION ‘...’ IN UPDATE TASK, é criado no R/3 o mecanismo de asynchronous update. Neste caso a requisição é direcionada para uma tabela (a VBLOG) existente fisicamente no banco de dados que age como um buffer intermediário onde as requisições de atualização são enfileiradas.

Esta tabela contém basicamente o nome da rotina que será disparada para efetuar a atualização e os dados (parâmetros) para a rotina efetuar as atualizações necessárias.


Transações que são canceladas pelo usuário não tem o seu registro de header completado na VBLOG e portanto suas atualizações não são efetuadas.

Os registros de atualização podem ser divididos em componentes V1 e V2. Basicamente processos que são críticos são armazenados em componentes V1 e processos secundários que são menos time-criticals são armazenados nos componentes V2. Informações de estatísticas caem nesta segunda categoria.

O processo assíncrono de update é disparado pelo comando COMMIT WORK especificado no último dialog step de uma SAP transaction.

Nesta fase que ocorre na segunda parte da SAP-LUW, os registros escritos na VBLOG são recuperados e atualizados fisicamente na base de dados.

Caso ocorram erros nesta fase em processos V1, as alterações no DB daquela DB-LUW são desfeitas por rollback e os registros permanecem na VBLOG assinalados com um flag de erro. Caso ocorram erros em processos V2, apenas aquele registro será setado com erro e as demais atualizações V2 continuam sendo executadas.

Quando ocorrem os error descritos acima, o usuário é notificado através de mail e medidas corretivas precisam ser avaliadas.

Ao término da SAP-LUW, a task de update remove os locks postados pelos dialog steps anteriores. Caso ocorram erros durante o update os locks também serão removidos.

Updates pendentes com erro podem ser restartados pelo administrador do sistema. A SAP não recomenda que updates V1 sejam restartados, devendo este procedimento somente ser efetuado para updates dos tipo V2. Processos V1 deverão ser regerados processando novamente a transação (veja nota 16083)

Quando um sistema R/3 sai, as entradas que estão com status INIT na VBLOG são processadas tão logo o sistema retorne ao ar. Esta funcionalidade pode ser parametrizada pela profile do sistema.

Background Processing

Processos que são schedulados para processamento pelos background work processes são tratados no sistema da mesma forma que os processos online.

Processos background são schedulados na forma de jobs. Cada job possui um ou mais steps (que podem ser external ou ABAP programs) que são processados sequencialmente.

Através das classes de processamento (A, B ou C) é possível setar prioridades entre os jobs.

Os jobs batch normalmente não são schedulados para processamento imediato, mas são especificados para uma data/hora futura podendo ainda, quando necessário, serem definidos como periódicos.

O batch scheduler é o responsável pelo disparo automático dos jobs configurados no sistema. Este módulo é um programa ABAP que roda em um dialog work process e ao


varrer a tabela de scheduling e encontrar um job candidato o encaminha para processamento pelos background work processes.

O sistema efetua balanceamento de carga para distribuir os jobs batch entre os diversos servers que possuem work processes disponíveis (do tipo B). Jobs batch podem ainda ser schedulados para processamento em servers específicos.

Na escala de prioridade Jobs classe A tem maior prioridade que os classe B e por último os jobs classe C. Dentro de um mesmo servidor e jobs schedulados com a mesma classe, tem prioridade aquele schedulado com especificação explícita de server (sem balanceamento)

R/3 Printer Services

Spooling é a transferência bufferizada de dados para dispositivos de saída do tipo printers, fax, etc. O R/3 suporta spooling para dispositivos locais ou em rede.

As requisições de spool são geradas tanto pelo processamento online (dialog) quanto pelo processamento batch (background). Os dados a serem impressos ficam armazenados nos TemSe (Temporary Sequential Objects).

Quando o sistema necessita de impressão, é gerado um spool request que é encaminhado para um spool work process. Uma vez formatado o dado para impressão, a requisição de impressão é encaminhada para o spool do sistema operacional, que fica responsável pelo encaminhamento do spool para o dispositivo de saída.

R/3 Instance

Uma instancia R/3 é uma unidade administrativa que combina componentes de um sistema R/3 para prover um ou mais serviços. Todos os serviços providos por uma instancia são iniciados (start da instancia) e parados (stop da instancia) ao mesmo tempo.

Uma instancia é parametrizada através de parâmetros que descrevem todas as suas características.

Cada instancia possui seus próprios buffers e um sistema R/3 central é composto de uma única instancia que possui todos os serviços (DVEBMSGnn)

O message server é o responsável pela comunicação entre os application servers e um central message service para prover serviços de update trigger, enqueue e dequeue, background requests, por exemplo.

Cada dispatcher de um application server se comunica com um único message server em cada ambiente R/3, que portanto só é instalado uma única vez na central instance. Até mesmo os presentation (SAPGUI) poderão se logar nos application server através do message server para desta forma efetuar balancemento automático de carga (load balancing)

São as profiles que configuram as diversas instancias e desta forma definem quem executa quais serviços.


Interfaces

R/3 as an Open System

O R/3 é um sistema aberto que permite a comunicação com várias outras plataformas, quer seja entre as instancias de um sistema R/3 ou com outros sistemas R/3, R/2 ou sistemas não SAP através de rede

Comunicação em rede pode ser dividida em 7 camadas, onde cada camada serve de interface entre a camada de baixo e camada de cima. Do ponto de vista da programação, desenvolver uma comunicação entre sistemas é mais fácil a medida que esta conversa é implementada nas camadas mais superiores.

A SAP suporta os protocolos TCP/IP e SNA LU6.2. A comunicação entre sistemas R/3 se dá em TCP/IP e a comunicação LU6.2 é utilizada para a comunicação com sistemas R/2 baseados em mainframe.

A programação R/3 suporta ainda CPI-C, RFC e OLE Automation como interfaces de comunicação. Os dois primeiros protocolos são proprietários da SAP e o OLE é um protocolo da Microsoft para a comunicação entre aplicativos na plataforma windows

R/3 Gateway Service

O SAP Gateway é o CPI-C handler, responsável pela conexão entre os protocolos TCP/IP e LU6.2, utilizado para a conexão entre sistemas R/3 e sistemas R/2 baseados em mainframe

O Gateway pode rodar tanto em um application server quanto em um database server

Pequenas mensagens, como visto anteriormente, fluem entre os application e a central instance em um sistema R/3 através do message server. Já os volumes mais elevados de dados, tais como os dados da aplicação fluem através do gateway.

Com isto podemos ver que a comunicação através do gateway tanto pode se dar dentro de um sistema R/3 quanto entre um sistema R/3 e um sistema R/2 ou com programas externos. O gateway utiliza o protocolo TCP/IP para comunicação com os clients e LU6.2 apenas para a comunicação com mainframes.

Communication with CPI-C

O CPI-C é um protocolo utilizado para a comunicação elementar program-to-program. É utilizada basicamente para a comunicação entre sistemas R/2 e outros aplicativos mainframe. É a implementação SAP da LU6.2

A comunicação faz uso dos verbos básicos da comunicação LU6.2 (INIT, ALLOCATE, ACCEPT, SEND, RECEIVE e DEALLOCATE)

É um protocolo de comunicação que exige que enquanto um parceiro esteja transmitindo o outro se encontre em modo de escuta, e vice versa.


Os parâmetros enviados pelo comando INIT são definidos através da tabela TXCOM e mantidos pela transação SM54.

Remote Function Call

O RFC é uma interface de comunicação baseada em CPI-C mas que possui mais funções além de ser mais simples de se utilizar. Pode ser utilizada para a comunicação entre sistemas R/3, R/3 com R/2 bem como aplicações externas.

O RFC permite a chamada de subrotinas remotamente pela rede. Estas subrotinas são chamadas de function modules. Estas funções possuem parâmetros e retornam valores como qualquer outra função e são gerenciadas dentro do R/3 através de sua própria function library, denominada Function Builder.

O Function Builder (transação SM37) dá ao programador uma excelente ferramenta para programar, documentar e testar as function modules, que tanto podem ser chamadas em modo local quanto remotamente. O Sistema R/3 gera automaticamente todo o protocolo necessário para a comunicação RFC entre os sistemas.

Os requerimentos para o RFC são os mesmos para o CPI-C. Os parâmetros para a comunicação RFC são mantidos través da transação SM59.

O R/3 vem ainda acompanhado de uma biblioteca de funções C para comunicação externa via RFC com o R/3, o RFC-SDK (Software Development System)

O que diferencia uma chamada RFC local de uma remota é apenas o parâmetro (destination) que especifica onde o comando será executado

Existem três tipos de chamadas RFC Synchronous RFC call, onde o programa que emitiu a chamada suspende a

execução até o retorno da chamada Asynchronous RFC call, onde a função chamada roda em paralelo e independente

do programa que emitiu o comando. O programador fica responsável pela conexão lógica dos resultados obtidos

Transactional RFC call, onde várias funções são agrupadas em uma única transação que é executada no sistema remoto como uma única LUW na sequencia com que elas foram codificadas. Caso ocorra um erro, o sistema que emitiu o comando recebe um código de retorno que pode ser consultado pela transação SM58. Ainda neste caso o sistema destino não precisa estar disponível no momento em que o comando é emitido, podendo ainda ser parametrizado o intervalo entre os queries.

Business Objects and BAPIs

Os business objects formam a base para a comunicação em alto nível no sistema R/3, tornando possível por exemplo implementações R/3 na internet e tem as seguintes características: Formam a base para uma bem sucedida comunicação em sistemas client/servers São orientados ao negócio. Existem BAPIs chamados Customer, Order, etc.


Possui métodos, que são os business functions que facilitam e padronizam a utilização destes objetos

São gerenciados internamente pelo R/3 em uma biblioteca central, a Business Object Repository, ou BOR

As BAPIs (Business Application Programming Interfaces) são interfaces funcionais que utilizam business methods para executar funções de negócio. Elas podem ser chamadas tanto pelos programas R/3 quanto encapsuladas e instanciadas por programas externos.

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

O OLE (Object Linking and Embedding) é uma forma de comunicação entre programas orientada para objeto. Com isto é possível conectar aplicações desktop que utilizam OLE2 (Word, Excell, etc.) com o sistema R/3

Quando o sistema R/3 está agindo como um client OLE, o usuário chama o programa (word, excell) de dentro do programa ABAP. Os comandos OLE são transferidos para o PC através de chamadas RFC

Os objetos OLE aos quais o R/3 pode se conectar como client são definidos internamente no R/3 (através de type informations) onde se definem os métodos, atributos e parâmetros do objeto. A linguagem ABAP possui comandos próprios (CREATE OBJECT, CALL METHOD, GET/SET PROPERTY e FREE OBJECT) que permitem instanciar e manipular o objeto.

Quando o R/3 funciona como um OLE server, suas funções podem ser chamadas de dentro das aplicações que rodam no desktop. Estas chamadas são enviadas ao SAP Automation Server que converte os calls para RFCs que são enviados ao sistema R/3. Estas chamadas ativam BAPIs ou function modules dentro do sistema R/3 que processam as informações que são então enviadas de volta para o Automation Server que a repassa para o aplicativo no desktop.

Do ponto de vista da programação, usuários podem utilizar as function modules do R/3 em uma programação orientada para objeto, como por exemplo utilizando C++ ou Visual Basic. Isto é válido para todos os objetos que são gerenciados centralizadamente pelo R/3 através da BOR (Business Object Repository)

Como os BOR e function modules se encontram no R/3, para utiliza-los é necessário antes efetuar um logon, que pode ser feito de forma automatizada pelo programa.

Internet Architecture

O IST (Internet Transaction Server) forma o componente principal da arquitetura Internet da SAP. Ele é composto de dois componentes, o Application Gate (A Gate) e o Web Gate (W Gate)

Do ponto de vista do R/3, o A Gate age como um usuário comum, uma vez que o IST converte toda a conversa com o sistema para protocolos utilizados pelo SAPGUI. O A Gate mescla os dados recebidos com templates HTML e os envia através do W Gate


para o HTTP server, onde são finalmente exibidos para o usuário através dos browsers padrão (explorer ou netscape)

A SAP fornece o IAC (Internet Application Component) que possui Web Transactions que nada mais são que mapeamentos Web de transações standard R/3. Assim como qualquer página HTML, o usuário pode customizar o lay out de acordo com suas necessidades.

EDI Architecture

O Electronic Data Interchange é uma forma estruturada e eletrônica para trocar informações entre diversos sistemas. Esta arquitetura tem as seguintes características: EDI-enabled applications, que permite que transações de negócio sejam processadas

automaticamente A interface IDOC, que foi criada como uma interface aberta e consiste de

documentos intermediários e seus respectivos function modules O subsystem EDI, que converte os documentos intermediários em mensagens EDI e

vice versa. O SAP não implementa esta facilidade

O componente principal desta interface é o Idoc, que é um SAP standard que especifica a estrutura e o formato do dado que está sendo transferido

Distribution of Business Processes with ALE

Por razões técnicas ou de negócio pode ser necessário fazer uma implementação descentralizada do R/3. O conceito ALE (Application Link Enabling) permite configurar e operar aplicações distribuídas em SAP.

O ALE consiste de uma troca controlada de mensagens de negócio que permitem a integração consistente de sistemas distribuídos. Os aplicativos são integrados através de comunicações tanto síncronas quanto assíncronas.

Para especificar um sistema distribuído é necessário especificar o modelo lógico em que o sistema rodará e ainda entre quem e como os dados deverão ser intercambiados

Os dados são transferidos através de Idocs (Intermediate Documents) através da interface EDI.

Data Transfer and Batch Input

Quando se transfere dados entre sistemas R/3 ou entre o legado e o R/3, é importante garantir que estes dados entrem de forma consistente dentro do sistema.

Desde que se utilize as mesmas transações conversacionais utilizadas pelos usuários para entrar com os dados no sistema, fica assegurado que os dados passarão pelas mesmas consistências que se efetuam nas entradas online de informação

O método comumente utilizado para entrada de dados do legado é conhecido como batch input. A SAP provê uma série de métodos implementados através de técnicas de batch input para a transferência de dados do legado. Estes métodos standard são


controlados através do Data Transfer Workbench (transação SXDA). Caso não existam SAP standard disponível, é possível definir e criar seus próprios métodos

O método consiste na bufferização das operações em uma BDC table (Batch Data Communication) que fica organizada em uma fila (batch input session). No passo seguinte esta fila é processada e os dados são transferidos para a base de dados. O método funciona como uma screen cam para processamento de transações

Um outro método para entrada de dados é o CALL TRANSACTION que força a chamada de uma transação para processar os dados armazenados na BDC table

Tanto o batch input quanto o método de call transaction chamam os mesmos programas que são processados em dialog mode pelos usuários, o que garante desta forma que as mesmas consistencias sejam efetuadas sobre a massa de dados.

Outra forma de atualização é o Direct Input, onde os dados são lidos diretamente do arquivo de entrada, consistidos e transferidos para a base de dados sem passar pelas funções de aplicação normais. Dado a natureza atípica desta operação, ela é efetuada apenas por algumas poucas funções R/3 e reservadas apenas para programas desenvolvidos pela própria SAP.

R/3 Graphical User Interface

Frontend Administration

Usuários não necessitam da mesma configuração em seus PCs, embora uma padronização da workstation simplifica o trabalho de administração.

Considere a facilidade e a dificuldade para atualizar os softwares da estação

Frontend Requirements

A nota 86895 descreve detalhadamente a configuração da estação

Configuração para Windows 95Item Configuração Mínima Configuração desejávelProcessador 486 Pentium 133 RAM 16MB 32MBNet connection Winsocket API Winsock.dll

Configuração para Windows NTItem Configuração Mínima Configuração desejávelProcessador Pentium 90 Pentium 133 RAM 32MB 48MBNet connection TCP/IP TCP/IP

Para testar o funcionamento da rede entre a estação e o host basta efetuar um ping ou telnet. As configurações no windows ficam nos arquivos host e services

Para testar o funcionamento do SAPGUI utilize o comandoAcademia Basis – Semana 1 - 26/01 a 28/01/2000 Pag. 20José Roberto A. de Lima – SAP Brasil

sapgui <appserver> sapdp<nn>

SAPGUI Installation

Sempre que for instalar uma nova versão do SAPGUI é necessário deletar a versão anterior. O programa sappurge.exe pode ser utilizado para esta finalidade.

A instalação é feita individualmente em cada PC. Programe a melhor forma para otimizar o trabalho

O arquivo SAPSETUP.INI pode ser editado para parametrizar a instalação. Nele se configura quais os componentes a serem instalados e os diretórios target e de work.

O sapsetup permite uma instalação dialog free startada a partir da linha de comando (veja o R/3 Installation Guide) o que assegura uma distribuição automática do software e a manutenção do frontend utilizando logon scripts.

A vantagem neste tipo de instalação é que a configuração das estações é feita a partir de uma localização central através de um logon script, que faz todas as checagens necessárias (hardware e network) e executa as operações necessárias para instalar e manter o frontend.

A desvantagem deste método é que se tem mais trabalho para implementar o check de versão no logon script e para analisar os resultados da instalação no arquivo sapsetup.log

A SAP recomenda que sob windows 95 e NT primeiro se faça uma instalação em um servidor (installation server) utilizando o installation wizard e posteriormente se instale os clients a partir dele. O programa utilizado na instalação é o \Gui\Windows\Win32\Sapsetup.exe

Types of Online Help

Existem diversos tipos de implementação do online help no R/3: PlainHtmlHelp converte documentos para HTML standard. Pode ser instalado em

todas as plataformas de frontends e é exibida através dos browsers convencionais. Pode ser utilizado tanto com Windows 95, NT ou ainda quando um Web server é disponível na instalação (intranet)

PlainHtmlFile converte documentos para HTML standard. Pode ser instalado em todas as plataformas de frontends e os documentos são acessados através de um file server que disponibiliza os dados de um diretório por compartilhamento onde são exibidos através dos browsers convencionais nas estações. Pode ser utilizado tanto com Windows 95, NT ou ainda quando um Web server é disponível na instalação (intranet)

HtmlHelpFile converte documentos armazenados no formato HTML comprimido para Html convencional. Pode ser utilizado apenas em estações Windows 95 ou NT. É instalado em um file server compartilhado, como o anterior, mas sua principal vantagem é que o espaço necessário no file server é cerca de 90% menor, já que os arquivos se encontram compactados. O único pré requisito é que o browser já esteja


instalado na estação antes da instalação do SAPGUI, já que é o browser que contém todos os HTML controls necessários.

O tipo de help e sua localização são especificados como parâmetros nas profiles do R/3

A configuração do arquivo SAPDOCCD.INI no frontend overrida a definição genérica das profiles do R/3

SAPLOGON

O programa saplogon.exe se encontra no diretório drive:\<target>\sapgui, conforme foi definido no momento da instalação. O saplogon utiliza o programa sapgui.exe para se conectar com o application server.

O arquivo saplogon.ini configura as entradas disponíveis na janela do saplogon e é mantido quando se atualiza as entradas disponíveis do usuário. As informações lá contidas são utilizadas para montar o string de conexão ao application server. Para evitar que o usuário edite as entradas deste arquivo é preciso defini-lo como readonly.

Ao se clicar no canto esquerdo da janela do saplogon é possível obter informações about que descrevem a localização dos dois arquivos (sapgui.exe e saplogon.ini)

O botão do canto superior esquerdo da janela permite ainda que se configure as opções de trace do saplogon e as funcionalidades de edição. Estas definições ficam armazenadas na seção [Configuration] do saplogon.ini

Assim como o saplogon.ini, os arquivos sapmsg.ini e saproute.ini são mantidos implicitamente quando edita as entradas do saplogon. O primeiro contém a relação dos message servers e seus respectivos serviços (logical service names) que será lido sempre que se efetua uma requisição de logon a um logon group através do saplogon. O segundo arquivo (saproute.msg) lista os saprouters que podem ser selecionados no saplogon.

Já o arquivo services do windows não é editado pelo saplogon embora possua entradas fundamentais para o seu funcionamento, devendo portanto ser editado em separado. Nele são especificadas entradas para os message servers definidos no sapmsg.ini, como por exemplo: sapms<SID> 36nn/tcp

O saplogon utiliza o programa sapgui.exe para se conectar com o sistema R/3 e o string de conexão depende do target escolhido: Para conexão com uma instancia R/3: sapgui /H/<appserver>/S/32nn Para conexão com um message server: sapgui /M/<host name>/S/36nn/G/<logon

group> Para conexão saprouter: sapgui /H/<host 1>/S/3299/H/<host 2>/S/3299/H/<oss

host>/S/36nn/G/Public

Os números dos serviços poderão ser substituídos pelas respectivas entradas colocadas no services: sapdp<nn> para o dispatcher e sapms<SID> para o message server


SAP MAPI

SAP Online Service System (OSS)

OSS Overview

O OSS é um serviço 24 x 7 disponibilizado pela SAP que permite acesso ao banco de dados de Notas, que provêm soluções para problemas no sistema R/3

Através do OSS os clientes abrem chamados ao suporte relatando problemas que são analisados pela equipe da SAP

OSS Functionality

A tela de pesquisa permite entrar com palavras chave relacionadas ao problema e incluir filtros na pesquisa, tais como release, database, versão de Hot Package, etc.

Ao abrir chamados, o OSS já configurado com dados gerais da sua instalação requisita informações sobre área do problema, transação, descrição do problema e severidade.

O SSCR é uma funcionalidade do OSS que permite ao cliente obter key para desenvolvedores e para os objetos SAP que irão sofrer modifications.

O SSCR exibe uma lista de todos os objetos e desenvolvedores registrados para o cliente na SAP

Através da lista de Hot Packages disponíveis e das datas dos treinamentos oferecidos pela SAP

OSS Access

O acesso ao OSS é efetuado através da transação OSS1, que abre uma nova conexão SAPGUI no frontend do usuário

O acesso ao OSS é preciso ser configurado através de um SAPRouter gateway que abre uma conexão segura entre a instalação do cliente e a rede mundial da SAP.

SAPNet

A SAPNet é uma ferramenta que provê informações e serviços via internet. O acesso a SAPNet é feito através da área CUSTOMER PARTNER da página pública da SAP (WWW.SAP-AG.DE)

Dentro da SAPNet existem áreas de Assistência, Informação, Comunicação e Serviços


http://WWW.SAP-AG.DE/

SAP TechNet

A SAP TechNet é uma ferramenta focada mais para o lado técnico, acessada através de endereço www.sap.com/technet ou através da área de communication da SAPNet

Os assuntos na SAP TechNet estão divididos por áreas de interesse e podem ser navegados para encontrar uma grande diversidade de documentos e pdfs


http://www.sap.com/technet

Date post:	27-Jun-2015
Category:	Documents
Upload:	cleiton-folster-eli
View:	334 times
Download:	8 times