SAP R / 3 Archiarquitetura
Equipe editorial
⚡ Resumo Inteligente
SAP R / 3 ArchiA arquitetura ABAP é um projeto cliente-servidor de três camadas que separa as responsabilidades de apresentação, aplicação e banco de dados. Este artigo explica cada camada, o ABAP e... Java pilha de componentes, o processo de logon orientado pelo dispatcher e os motivos. SAP Escolhi este modelo em camadas.
SAP R / 3 ArchiA arquitetura é a base de quase todos os clássicos. SAP Implantação de ERP. As seções abaixo explicam como as três camadas interagem e como o ABAP e Java As pilhas dividem o trabalho entre o despachante, o servidor de mensagens e o banco de dados.
O que é a SAP R/3?
SAP O R/3 é um sistema empresarial cliente-servidor construído sobre uma plataforma arquitetura de três camadas consistindo em três camadas independentes:
- Apresentação
- Aplicação
- banco de dados
- R é um anagrama para Em tempo real processamento.
- 3 representa o De 3 camadas padrão arquitetônico.
Computador do usuário (interface do usuário): Os usuários acessam o SAP sistema através de SAP Interface gráfica do usuário (GUI) ou navegador web. Apenas o cliente front-end é instalado na máquina do usuário; os servidores de aplicação e banco de dados são executados separadamente em hardware dedicado.
Servidores de aplicativos: Os servidores de aplicativos executam a lógica de negócios. A carga de trabalho é distribuída entre vários servidores de aplicativos, permitindo que os usuários recebam respostas mais rapidamente sob alta demanda. Esses servidores geralmente são executados em infraestrutura remota, em vez de estações de trabalho dos usuários.
Servidor de banco de dados: O servidor de banco de dados armazena e recupera dados em resposta a SQL consultas geradas pelo ABAP e Java Aplicações. Os serviços de banco de dados e de aplicativos podem ser executados na mesma máquina ou em hosts físicos separados, dependendo das necessidades de capacidade.
Porque SAP O R/3 utiliza uma arquitetura de 3 camadas?
Separar a apresentação, a lógica de negócios e o armazenamento em três camadas independentes proporciona SAP O R/3 apresenta quatro vantagens práticas em relação aos projetos de camada única ou de duas camadas:
- Escalabilidade independente: Cada camada pode ser dimensionada separadamente. Um gargalo na lógica de negócios é resolvido adicionando servidores de aplicativos sem alterar o hardware do banco de dados.
- Distribuição da carga de trabalho: O servidor de mensagens distribui a carga das sessões recebidas entre os servidores de aplicativos, evitando que um único servidor se torne um ponto único de congestionamento.
- Proteção de banco de dados: Os usuários finais nunca se conectam diretamente ao banco de dados. Todas as operações de leitura e gravação passam pelos processos de trabalho do servidor de aplicativos, que padronizam as verificações de autorização, o bloqueio e o registro de transações.
- Upgrade flexibilidade: O SAP A interface gráfica do usuário (GUI) pode evoluir (clientes para desktop, navegador ou dispositivos móveis via SAPUI5) sem alterar o código do aplicativo ou do banco de dados.
Essa separação também é o que permite SAP para suportar múltiplos back-ends de banco de dados — incluindo SAP HANA, Oracle, IBM Db2 e Microsoft SQL Server — sob a mesma base de código da aplicação.
SAP R/2 vs SAP R/3: Como o ArchiTextura Evoluída
SAP O R/2 era executado em um mainframe e utilizava uma arquitetura de duas camadas, na qual o terminal do usuário se comunicava diretamente com o banco de dados. O R/3, lançado em 1992, inseriu uma camada de aplicação dedicada entre o cliente e o banco de dados. Os dois lado a lado:
| Aspecto | SAP R / 2 | SAP R / 3 |
|---|---|---|
| Plataforma | 2 camadas (mainframe + terminal) | 3 camadas (apresentação + aplicação + banco de dados) |
| Hardware | mainframe centralizado | Unix distribuído / Windows Servidores Linux |
| Global | Somente vertical (mainframe maior) | Horizontal (adicionar servidores de aplicativos) |
| Acesso ao banco de dados | Diretamente da sessão do usuário | Mediado por processos de trabalho do servidor de aplicativos |
| Modelo de programação | Somente ABAP/4 | ABAP e Java lado a lado |
As seções restantes explicam detalhadamente cada uma das três camadas do R/3.
Compreendendo diferentes SAP camadas
Figura 1: Os três SAP Camadas R/3 e o tráfego que flui entre elas.
Camada de apresentação
O Camada de apresentação contém os componentes de software que compõem o SAP GUI — a interface gráfica do sistema R/3. É a interface entre o sistema e seus usuários, fornecendo um layout intuitivo para entrada e exibição de dados.
Essa camada encaminha a entrada do usuário para o servidor de aplicativos e renderiza os dados recebidos como resposta. SAP Enquanto a interface gráfica do usuário (GUI) estiver em execução, ela permanecerá vinculada à sessão de terminal do usuário no sistema R/3 durante toda a duração dessa sessão.
Camada de aplicação
O Camada de aplicação consiste em um ou mais servidores de aplicativos e um servidor de mensagensCada servidor de aplicativos executa um conjunto de serviços que implementam a lógica de negócios do R/3. Em teoria, um único servidor de aplicativos é suficiente; na prática, os serviços são distribuídos por vários servidores para garantir capacidade e redundância.
O servidor de mensagens coordena a comunicação entre servidores de aplicativos. Ele encaminha solicitações, tracO sistema de gerenciamento de aplicações KS agrupa os servidores e atribui um servidor apropriado quando um usuário faz login, com base na carga atual. É isso que torna possível o escalonamento horizontal.
Camada de Banco de Dados
O Camada de Banco de Dados Abriga um sistema de banco de dados central que armazena todos os dados utilizados pelo sistema R/3. A pilha de banco de dados possui dois componentes: o sistema de gerenciamento de banco de dados (SGBD) e o próprio banco de dados. SAP envia seu próprio SGBD, SAP HANAe também suporta todos os principais bancos de dados comerciais (Oracle, IBM Db2, Microsoft SQL Server).
Todos os dados do R/3 — configurações de personalização, código do aplicativo, definições de tela, menus, módulos de função e dados de tempo de execução — residem neste banco de dados. O código do programa e os objetos de design ficam em uma seção especial chamada... Repositório R/3Esses “objetos de repositório” são o que o ABAP Workbench lê, grava e transporta entre sistemas.
Compreender os componentes de SAP R/3 3 níveis Archiarquitetura
Figura 2: ABAP + Java Arquitetura do sistema mostrando como as duas camadas compartilham a infraestrutura.
Um moderno SAP Uma instância do NetWeaver pode hospedar tanto ABAP quanto... Java Pilhas. Os componentes abaixo mostram como cada pilha lida com seu próprio despacho, compartilhando o gateway, o ICM e a ponte JCO para comunicação entre pilhas.
| Componente | CorMonitor | Tipo |
|---|---|---|
| Servidor de mensagens (ABAP) | ABAP | Coordena a comunicação entre despachantes distribuídos no Sistema ABAP e distribui a carga entre as instâncias. |
| Fila do despachante | ABAP | Buffer que retém as solicitações recebidas até que um processo de trabalho fique livre. |
| Expedidor | ABAP | Retira solicitações da fila e atribui cada uma ao tipo de processo de trabalho apropriado. |
| Processos de trabalho ABAP | ABAP | Executar etapas de diálogo em aplicações R/3. Os tipos incluem Diálogo, Atualização, Em Segundo Plano, Spool e Enfileirar. |
| Gateway | Partilhado | Permite a comunicação entre SAP sistemas e entre SAP e sistemas externos via RFC. |
| Tubos de memória | Partilhado | Transportar dados entre o Gerenciador de Comunicação da Internet (ICM) e os processos de trabalho ABAP. |
| Servidor de mensagens (Java) | Java | Coordenadas Java despachantes e processos de servidor; permite a comunicação dentro do Java cluster de tempo de execução. |
| Servidor de fila | Java | Gerencia bloqueios lógicos definidos por Java Código de aplicação em execução dentro de um processo de servidor. |
| Serviços Centrais | Java | A especial Java Instância de cluster que gerencia bloqueios e mensagens entre processos. Uma "instância" é um grupo de recursos (memória, processos de trabalho, etc.). |
| Java Expedidor | Java | Recebe solicitações de clientes e as encaminha para Java processos do servidor. |
| SDM | Java | Gerenciador de Implantação de Software — instala componentes J2EE no sistema. Java pilha. |
| Java Processos do servidor | Java | Processar um grande número de solicitações simultaneamente usando multithreading. |
| ICM | Partilhado | Gerenciador de Comunicação da Internet — habilita o tráfego HTTP, HTTPS e SMTP para SAP Pode ser acessado através de um navegador. |
| JCO | ponte | Java Conector — gerencia a comunicação entre os Java O dispatcher e o dispatcher ABAP, quando ambas as pilhas são executadas lado a lado. |
Figura 3: Categorias de processos de trabalho ABAP (Diálogo, Atualização, Segundo Plano, Spool, Enfileirar).
Como o SAP O processo de logon funciona?
Figura 4: Fluxo passo a passo do login de um usuário através do SAP Camadas de despacho e processos de trabalho do R/3.
Passo 1) O usuário clica no SAP sistema de SAP GUI; a solicitação é encaminhada para o expedidor.
Passo 2) A solicitação chega ao fila de solicitaçõesO despachante segue um primeiro a entrar, primeiro a sair regra e atribui a solicitação ao próximo processo de trabalho disponível.
Passo 3) Um processo de trabalho do tipo apropriado é atribuído. Um usuário que faz login recebe um processo de trabalho de Diálogo; um relatório em segundo plano recebe um processo de trabalho de Segundo Plano; uma instrução UPDATE é encaminhada para um processo de trabalho de Atualização. A ação determina o tipo de processo de trabalho.
Passo 4) Assim que o processo de trabalho de Diálogo for atribuído, as autorizações e configurações atuais do usuário serão atualizadas. rolou para a memória compartilhada, para que o processo de trabalho possa atuar sobre os dados do usuário. Quando a etapa de diálogo termina, esses dados são desenrolou Para liberar a memória para o próximo usuário. Uma "etapa de diálogo" é a transição de uma tela para outra dentro de uma transação.
Passo 5) O processo de trabalho primeiro procura os dados solicitados no buffer. Encontrá-los lá é chamado de busca. acertar e evita uma consulta completa ao banco de dados, melhorando o tempo de resposta. Não encontrá-lo aciona um perder e uma leitura de banco de dados. Uma alta taxa de acertos em relação a erros é o maior fator que contribui para SAP desempenho.
Passo 6) Os dados restantes são consultados no banco de dados e o resultado combinado é enviado de volta para o sistema. SAP Interface gráfica do usuário (GUI) através do despachante.
Passo 7) Os dados da sessão do usuário são removidos da memória compartilhada em um processo final. roll-out, liberando a área de memória para a próxima solicitação.
O mesmo ciclo de despachante → fila → processo de trabalho → buffer → distribuição se repete para cada interação do usuário, independentemente de a solicitação se originar de SAP GUI, um navegador via ICM ou um sistema externo através do gateway.
