SAP R / 3 Architectura
jessica blake
⚡ Resumen inteligente
SAP R / 3 ArchiLa arquitectura es un diseño cliente-servidor de tres niveles que separa las responsabilidades de presentación, aplicación y base de datos. Este artículo explica cada capa, el ABAP y Java pila de componentes, el proceso de inicio de sesión controlado por el despachador y las razones SAP Elegí este modelo por capas.
SAP R / 3 ArchiLa arquitectura sustenta casi todos los clásicos. SAP Implementación de ERP. Las secciones siguientes explican cómo interactúan los tres niveles y cómo ABAP y Java Las pilas dividen el trabajo entre el despachador, el servidor de mensajes y la base de datos.
¿Qué es SAP ¿R/3?
SAP R/3 es un sistema empresarial cliente-servidor construido sobre una base arquitectura de tres niveles consta de tres capas independientes:
- Presentación
- Aplicación
- Database
- R son las siglas de Gestión del riesgo procesar.
- 3 representa el 3 niveles patrón arquitectónico.
PC del usuario (interfaz de usuario): Los usuarios acceden al SAP sistema a través SAP Interfaz gráfica de usuario (GUI) o navegador web. Solo el cliente de interfaz se instala en el equipo del usuario; los servidores de aplicaciones y de bases de datos se ejecutan por separado en hardware dedicado.
Servidores de aplicaciones: Los servidores de aplicaciones ejecutan la lógica de negocio. La carga de trabajo se distribuye entre varios servidores de aplicaciones para que los usuarios reciban respuestas más rápidas incluso con mucha carga. Estos servidores suelen funcionar en infraestructura remota, en lugar de en las estaciones de trabajo de los usuarios.
Servidor de base de datos: El servidor de base de datos almacena y recupera datos en respuesta a SQL consultas generadas por ABAP y Java aplicaciones. Los servicios de base de datos y de aplicación pueden ejecutarse en la misma máquina o en hosts físicos separados, según las necesidades de capacidad.
¿Por que SAP ¿R/3 utiliza una arquitectura de tres niveles?
Separar la presentación, la lógica de negocio y el almacenamiento en tres niveles independientes proporciona SAP R/3 ofrece cuatro ventajas prácticas sobre los diseños de una o dos capas:
- Escalabilidad independiente: Cada capa se puede escalar de forma independiente. Un cuello de botella en la lógica de negocio se resuelve añadiendo servidores de aplicaciones sin modificar el hardware de la base de datos.
- Distribución de la carga de trabajo: El servidor de mensajería distribuye la carga de las sesiones entrantes entre los servidores de aplicaciones, evitando que un solo servidor se convierta en un único punto de contención.
- Protección de la base de datos: Los usuarios finales nunca se conectan directamente a la base de datos. Todas las operaciones de lectura y escritura se realizan a través de los procesos de trabajo del servidor de aplicaciones, que estandarizan las comprobaciones de autorización, el bloqueo y el registro de transacciones.
- Upgrade flexibilidad: El SAP La interfaz gráfica de usuario (GUI) puede evolucionar (clientes de escritorio, navegador o móviles a través de SAPUI5) sin modificar el código de la aplicación ni de la base de datos.
Esta separación es también lo que permite SAP para admitir múltiples sistemas back-end de bases de datos, incluyendo: SAP HANA, Oracle, IBM Db2 y Microsoft SQL Server — bajo la misma base de código de la aplicación.
SAP R/2 contra SAP R/3: Cómo el ArchiLa arquitectura ha evolucionado.
SAP R/2 se ejecutaba en un ordenador central y utilizaba una arquitectura de dos niveles en la que el terminal de usuario se comunicaba directamente con la base de datos. R/3, lanzado en 1992, insertó una capa de aplicación dedicada entre el cliente y la base de datos. Los dos sistemas, uno al lado del otro:
| Aspecto | SAP R / 2 | SAP R / 3 |
|---|---|---|
| Arquitectura de interiores | Arquitectura de dos niveles (ordenador central + terminal) | Arquitectura de 3 niveles (presentación + aplicación + base de datos) |
| Componentes metálicos | Computadora centralizada | Unix distribuido / Windows Servidores Linux |
| Escalabilidad organizacional | Solo vertical (ordenador central de mayor tamaño) | Horizontal (añadir servidores de aplicaciones) |
| Acceso a la base de datos | Directamente desde la sesión del usuario | Mediado por procesos de trabajo del servidor de aplicaciones |
| Modelo de programación | Solo ABAP/4 | ABAP y Java Juntos |
Las secciones restantes explican en detalle cada una de las tres capas R/3.
Entendiendo diferentes SAP ponedoras
Figura 1: Los tres SAP Las capas de R/3 y el tráfico que fluye entre ellas.
Capa de presentación
El Capa de presentación Contiene los componentes de software que componen el SAP GUI (Interfaz Gráfica de Usuario) — la interfaz gráfica del sistema R/3. Es la interfaz entre el sistema y sus usuarios, proporcionando un diseño intuitivo para introducir y visualizar datos.
Esta capa reenvía la entrada del usuario al servidor de la aplicación y renderiza los datos que recibe en respuesta. SAP La interfaz gráfica de usuario (GUI) está en funcionamiento y permanece vinculada a la sesión de terminal del usuario en el sistema R/3 durante toda la duración de dicha sesión.
Capa de aplicación
El Capa de aplicación consta de uno o más servidores de aplicaciones y un servidor de mensajesCada servidor de aplicaciones ejecuta un conjunto de servicios que ejecutan la lógica de negocio de R/3. En teoría, un solo servidor de aplicaciones es suficiente; en la práctica, los servicios se distribuyen entre varios servidores para garantizar la capacidad y la redundancia.
El servidor de mensajes coordina la comunicación entre los servidores de aplicaciones. Reenvía las solicitudes, tracEl servidor de aplicaciones ks agrupa los servidores y asigna el servidor adecuado cuando un usuario inicia sesión, en función de la carga actual. Esto es lo que posibilita el escalado horizontal.
Capa de base de datos
El Capa de base de datos Alberga un sistema de base de datos central que almacena todos los datos utilizados por el sistema R/3. La pila de la base de datos tiene dos componentes: el sistema de gestión de bases de datos (DBMS) y la base de datos propiamente dicha. SAP envía su propio DBMS, SAP HANAy también admite todas las principales bases de datos comerciales (Oracle, IBM Db2, Microsoft SQL Server).
Todos los datos de R/3 (configuraciones de personalización, código de aplicación, definiciones de pantalla, menús, módulos de función y datos de tiempo de ejecución) residen en esta base de datos. El código del programa y los objetos de diseño se encuentran en una sección especial llamada Repositorio R/3Estos "objetos de repositorio" son los que el entorno de desarrollo ABAP lee, escribe y transporta entre sistemas.
Comprender los componentes de SAP R/3 3 niveles Architectura
Figura 2: ABAP + Java Arquitectura del sistema que muestra cómo las dos pilas comparten infraestructura.
Un moderno SAP La instancia de NetWeaver puede alojar tanto ABAP como Java pilas. Los componentes que se muestran a continuación ilustran cómo cada pila gestiona su propio despacho, al tiempo que comparte la puerta de enlace, el ICM y el puente JCO para la comunicación entre pilas.
| Componente | Apilar | Rol |
|---|---|---|
| Servidor de mensajes (ABAP) | ABAP | Coordina la comunicación entre los despachadores distribuidos en el sistema ABAP y equilibra la carga entre las instancias. |
| Cola del despachador | ABAP | Buffer que retiene las solicitudes entrantes hasta que un proceso de trabajo quede libre. |
| Coordinadora de servicio | ABAP | Extrae las solicitudes de la cola y asigna cada una al tipo de proceso de trabajo apropiado. |
| Procesos de trabajo ABAP | ABAP | Ejecuta pasos de diálogo en aplicaciones R/3. Los tipos incluyen Diálogo, Actualización, Segundo plano, Cola de impresión y Encolado. |
| Gateway | Compartido | Permite la comunicación entre SAP sistemas y entre SAP y sistemas externos a través de RFC. |
| Tuberías de memoria | Compartido | Transferir datos entre el Gestor de Comunicaciones de Internet (ICM) y los procesos de trabajo ABAP. |
| Servidor de mensajes (Java) | Java | Coordenadas Java despachadores y procesos de servidor; permite la comunicación dentro del Java clúster de tiempo de ejecución. |
| Servidor de cola | Java | Gestiona los bloqueos lógicos establecidos por Java Código de aplicación que se ejecuta dentro de un proceso de servidor. |
| Servicios Centrales | Java | ¡Un especial Java Instancia de clúster que gestiona el bloqueo y la mensajería entre procesos. Una “instancia” es un grupo de recursos (memoria, procesos de trabajo, etc.). |
| Java Coordinadora de servicio | Java | Recibe las solicitudes de los clientes y las reenvía a Java procesos del servidor. |
| SDM | Java | Administrador de despliegue de software: instala componentes J2EE en el Java asociación. |
| Java Procesos del servidor | Java | Procese un gran número de solicitudes simultáneamente mediante el uso de subprocesos múltiples. |
| ICM | Compartido | Administrador de comunicaciones de Internet: permite el tráfico HTTP, HTTPS y SMTP, por lo que SAP Se puede acceder a él desde un navegador. |
| JCO | Puente | Java Conector: gestiona la comunicación entre el Java El despachador y el despachador ABAP cuando ambas pilas se ejecutan en paralelo. |
Figura 3: Categorías de procesos de trabajo ABAP (Diálogo, Actualización, Segundo plano, Cola de impresión, Encolado).
¿Cómo funciona el SAP ¿El proceso de inicio de sesión funciona?
Figura 4: Flujo paso a paso del inicio de sesión de un usuario a través del SAP Capas de despacho y procesos de trabajo de R/3.
Paso 1) El usuario hace clic en el SAP sistema de SAP GUI; la solicitud se reenvía a la despachador.
Paso 2) La solicitud llega a la cola de solicitudes. El despachador sigue un primero en llegar y primero en salir aplica la regla y asigna la solicitud al siguiente proceso de trabajo disponible.
Paso 3) Se asigna un proceso de trabajo del tipo apropiado. Un usuario que inicia sesión recibe un proceso de trabajo de diálogo; un informe en segundo plano recibe un proceso de trabajo de segundo plano; una instrucción UPDATE se entrega a un proceso de trabajo de actualización. La acción determina el tipo de proceso de trabajo.
Paso 4) Una vez asignado el proceso de trabajo de diálogo, las autorizaciones del usuario y la configuración actual son: rodó a memoria compartida para que el proceso de trabajo pueda actuar sobre los datos del usuario. Cuando finaliza el paso de diálogo, esos datos son desplegado para liberar la memoria para el siguiente usuario. Un “paso de diálogo” es el movimiento de una pantalla a otra dentro de una transacción.
Paso 5) El proceso de trabajo primero busca los datos solicitados en el búfer. Encontrarlos allí se llama hit y evita un viaje de ida y vuelta a la base de datos, mejorando el tiempo de respuesta. No encontrarlo activa una perder y una lectura de base de datos. Una alta relación de aciertos a fallos es el mayor contribuyente a SAP rendimiento.
Paso 6) Cualquier dato restante se consulta en la base de datos y el resultado combinado se envía de vuelta a la SAP Interfaz gráfica de usuario a través del despachador.
Paso 7) Los datos de sesión del usuario se eliminan de la memoria compartida en un proceso final. desenrollar, liberando el área de memoria para la siguiente solicitud.
El mismo ciclo de despacho → cola → proceso de trabajo → búfer → despliegue se repite para cada interacción del usuario, independientemente de si la solicitud se origina en SAP Interfaz gráfica de usuario (GUI), un navegador a través de ICM o un sistema externo a través de la puerta de enlace.
