Unit 3 The System Kernel Objetivos de la Unidad. Después de completar esta unidad, usted será capaz de:

Esquema simple de cliente / servidor de configuraciones

Nombre de los procesos del servidor de aplicaciones SAP NetWeaver

Definir el término instancia y reconocer las características de una instancia central

Entender cómo funciona AS ABAP

Una lista de los procesos de AS ABAP y describir su propósito

Describa cómo las peticiones a AS ABAP se procesan Introducción. Los sistemas de SAP se utilizan para los procesos de negocio de mapeo o aplicaciones de negocios. Estas aplicaciones deben aplicarse independiente del entorno de hardware utilizado (sistema operativo, base de datos) en la mayor medida posible. Para ello, SAP NetWeaver proporciona dos entornos de ejecución diferentes: un entorno de ejecución ABAP (tipo de uso AS ABAP) y Java Runtime Environment (tipo de uso como Java). ABAP (Advanced Business Application Programming) es un lenguaje de programación desarrollado por SAP. Muchas aplicaciones de negocio de un sistema SAP están escritas en ABAP. ABAP ha sido optimizado para el desarrollo altamente escalable de aplicaciones de negocio. Los clientes pueden utilizar el ABAP Workbench para desarrollar aplicaciones completamente nuevas, así como mejorar y modificar las aplicaciones de SAP estándar. De este modo, toda la infraestructura, poderosa del AS ABAP se puede utilizar, que también apoya la creación de las aplicaciones más complejas por parte de grandes grupos de desarrolladores. El Servidor de aplicaciones de ABAP ofrece el entorno de ejecución para programas escritos en ABAP. SAP no sólo proporciona un entorno de ejecución de programas ABAP, sino también un entorno de ejecución de los programas de Java. AS Java es un servidor de aplicaciones de acuerdo con el Java 2 Enterprise Edition (J2EE) estándar. El lenguaje de programación Java fue introducido por primera vez por Sun Microsystems, Inc. en 1995. Java es un lenguaje de programación orientado a objetos e independiente de plataforma, que se ha extendido en muchas áreas. El concepto de Java permite el desarrollo de una amplia gama de diferentes tipos de aplicaciones - desde las aplicaciones clásicas de los applets utilizados en páginas web a las aplicaciones cliente / servidor. Java 2 Platform Enterprise Edition (J2EE) es un estándar del proveedor para una gran variedad de componentes de software que esencialmente tienen origen en el lenguaje de programación

Java. Sun utiliza la prueba de compatibilidad J2EE para asegurar que las especificaciones de Java 2 Enterprise Edition se observen. De acuerdo con la especificación J2EE de la lógica de la aplicación se empaqueta en Enterprise Java Beans (EJB). Que representan los componentes de programa de Java. Un contenedor implícito proporciona los componentes con los servicios del entorno de ejecución. Antes de hablar sobre varios cliente / servidor de configuraciones en el contexto de los sistemas SAP, primero tenemos que definir los conceptos que el cliente y el servidor. Hay básicamente dos maneras de hacer esto. En el punto de vista orientado a hardware, el término servidor significa que el servidor central en una red es el que proporciona datos, la memoria y los recursos para las estaciones de trabajo (clientes). En el punto de vista orientado a software, cliente y el servidor están definidos a nivel de proceso (servicio). Un servicio en este contexto es un servicio proporcionado por un componente de software. Este componente de software puede consistir en un proceso o un grupo de procesos (por ejemplo, un servidor de aplicaciones SAP Web) y entonces se llama un servidor para ese servicio. Los componentes de software que utilizan un servicio se llaman clientes. Al mismo tiempo, los clientes también pueden ser servidores de otros servicios específicos. La siguiente grafica clasifica los dos enfoques para las definiciones.

Figure 26: Hardware-Oriented View and Software-Orient En el contexto de los sistemas de SAP, los términos cliente y servidor se utilizan generalmente como se define en el punto de vista de software orientado. Client/Server Configuration for SAP Systems Los siguientes procesos se suelen utilizar para la aplicación de software de operación de negocios:

los procesos de presentación (por ejemplo, para desplegar pantallas).

Los procesos de aplicación (por ejemplo, para ejecutar aplicaciones de programas).

los procesos de base de datos ( por ejemplo, para manejar y organizar la base de datos).

Cuando usted está instalando y configurando un sistema SAP, usted necesita decidir cómo se van a distribuir los procesos necesarios entre el hardware disponible. Hay varias maneras de hacer esto, algunos de los cuales se describen detalladamente más adelante. Las configuraciones son ya sea de un solo nivel o de varios niveles, dependiendo del número de capas de hardware utilizados (véase el gráfico siguiente). El sistema SAP ECC es un ejemplo de software de aplicación empresarial.

En configuraciones de un solo nivel, todas las tareas de procesamiento (procesos de base de datos, aplicación y presentación) son realizadas por un equipo. Esto es clásico de tratamiento en ordenador central.

Configuraciones de dos niveles se implementan normalmente el uso de servidores especiales de presentación que son responsables exclusivamente para el formato de la interfaz gráfica.

En una configuración de tres niveles, cada nivel se ejecuta en su propio host. Muchos servidores de aplicaciones diferentes al mismo tiempo pueden trabajar con los datos de un servidor de base de datos.

Figure 27: Simple Client/Server Configurations (Single-tier) Configuraciones de un solo nivel se utilizan generalmente para pruebas y demostraciones (por ejemplo, un sistema SAP en un ordenador portátil). Si muchos usuarios quieren trabajar en un sistema configurado de esta manera, entonces los costes de hardware adicional para cada usuario adicional a ser mayores que los costos asociados con la implementación de los niveles adicionales de hardware (por ejemplo, mover los procesos de presentación a otras máquinas). (two-tier) La configuración de dos niveles con los procesos de presentación distribuidos (como se muestra en el gráfico anterior) se puede mantener un buen rendimiento para un número significativamente mayor de usuarios, sin aumentar sustancialmente los costes de hardware. La carga resultante de los procesos de presentación se distribuye a los diversos frontales ordenadores y así no influye en el rendimiento de la máquina de base de datos. Sin embargo, si el número de usuarios supera un cierto límite superior, el sistema central, en el que tanto los procesos de aplicación y base de datos, corren el riesgo de convertirse en un cuello de botella. Para evitar esto, usted puede mejorar el rendimiento del sistema SAP mediante la distribución de los procesos de la capa de aplicación a varios equipos. Otra de las

ventajas de añadir una capa de hardware específicamente para los procesos de aplicación es que facilita la escalabilidad. Si el número de usuarios de SAP en un sistema aumenta con el tiempo, afectando negativamente el rendimiento del sistema, a continuación, este problema puede, en la mayoría de los casos, ser resuelto simplemente mediante la adición de otro host para los procesos. Una alternativa de dos niveles (two-tier) de configuración es la instalación de potentes sistemas de escritorio y que los utilicen para la presentación y las aplicaciones de dos niveles (cliente / servidor). Estas configuraciones son especialmente adecuados para aplicaciones con exigencias de procesador alto (por ejemplo, simulaciones o para los desarrolladores de software), pero no se aplican en el entorno SAP, que no sea con fines de prueba, debido a la administración adicional. En el entorno de SAP Business Suite, más complejas de cliente / servidor que consiste en configuraciones de más de tres pisos son teóricamente posible y en la práctica. Un nivel adicional podría ser un servidor web, por ejemplo. The Instance Una instancia es una unidad administrativa que combina los componentes del sistema SAP que ofrecen uno o más servicios. Los servicios prestados por una instancia se inician o se detiene junto. Se utiliza un perfil de instancia común para establecer los parámetros de todos los componentes de una instancia. Cada instancia tiene sus propias áreas de amortiguamiento. Una instancia se ejecuta en un equipo físico, pero no puede haber varias instancias en un solo ordenador. Una instancia se ejecuta en un equipo físico, pero no puede haber varias instancias en un solo ordenador. Un instancia es identificado por el ID del sistema (SID) y el número de instancia.

Sugerencia: Los términos (SAP) de la instancia y servidor de aplicaciones se utilizan a menudo como sinónimos.

Figure 28: Instances of an SAP System (Example) Cuando se instala un sistema SAP, ya tienes la opción de separar los procesos a nivel de aplicación de las mismas a nivel de base de datos. Esto significa que la base de datos para un sistema SAP puede ser instalado y operado en un equipo físico independiente, separada de las instancias del sistema SAP. No es exactamente una base de datos para cada sistema SAP. La

base de datos tiene generalmente el mismo sistema de identificación (ID DB) como el sistema SAP. La instancia central del sistema SAP se distingue por el hecho de que ofrece los servicios que ninguna otra instancia del sistema ofrece. Para el AS ABAP, estos son los mensajes del servidor y el proceso de puesta en cola de trabajo (ver abajo). Para el AS Java que uno reconoce la instancia central por el Software Deployment Manager (SDM). Los servicios de instancia centrales proporciona servicios centrales de la AS Java, el Servicio de Mensajes (Message Service)y el servicio de puesta (Enqueue Service) en cola (ver más abajo). Para el AS ABAP, estos servicios también se pueden mover a la instancia central de ABAP servicios por razones de alta disponibilidad. Estos sistemas de AS ABAP por lo tanto, ya no tienen una instancia central. Todas las demás instancias del sistema se suele denominar instancias de diálogo. Si la instancia central y la base de datos (y para el AS Java también la instancia de servicios centrales) están instaladas en el mismo equipo, esto se conoce como un sistema central. Processes of the SAP NetWeaver Application Server El sistema SAP tiempo de ejecución se compone de un gran número de procesos paralelos que trabajan juntos. Aquí, se puede distinguir entre el entorno de ejecución de ABAP (AS ABAP) y el entorno de ejecución de Java (como Java). AS ABAP Processes

Figure 29: AS ABAP Processes En el AS ABAP, estos procesos en cada servidor de aplicaciones incluyen el despachador así como un número de procesos de trabajo en función de los recursos de hardware:

El dispatcher distribuye las solicitudes a los procesos de trabajo.

Procesos de diálogo de trabajo (Dialog work process) cumplen todas las solicitudes para la ejecución de pasos de diálogo provocadas por un usuario activo.

Spool work process pasan los flujos de datos secuenciales a las impresoras. Al menos un proceso de trabajo spool se requiere para cada sistema SAP. Es posible configurar más de un proceso de trabajo de impresión para cada distribuidor.

Update work process ejecuta las solicitudes de actualización. Al igual que en los procesos de trabajo spool, usted necesita por lo menos un proceso de trabajo de actualización por el sistema SAP, y se puede configurar más de una por despachador.

Background work process ejecutan programas que se corren sin interactuar con el usuario. Necesita al menos dos procesos de trabajo de background para cada sistema SAP. Puede configurar más de un proceso de trabajo de background para cada distribuidor.

Enqueue work process administra la tabla de bloqueos en la memoria compartida. La tabla de bloqueos de base de datos contiene los bloqueos lógicos del entorno de ejecución ABAP de SAP. Sólo un proceso de puesta en cola de trabajo que se necesita para cada sistema.

Internet Graphics Server (IGS) es una infraestructura que los desarrolladores de aplicaciones pueden utilizar para mostrar gráficos en un navegador de Internet con un mínimo esfuerzo. El IGS está integrado en las diferentes tecnologías de interfaz de usuario de SAP GUI para HTML de la Web Dynpro ABAP / Java y ofrece una arquitectura de servidor donde los datos de un sistema SAP o de otra fuente se puede utilizar para generar salida gráfica y no gráfica. Con SAP Web AS 6.40, la IGS está disponible como un componente fijo de SAP Web AS y se instala cada vez que SAP Web AS instalación (tanto para los sistemas basados en AS ABAP y para los sistemas basados en AS Java). Con SAP Web AS 6.20 ya hay un motor independiente en ordenadores con Windows de 32 bits, por tanto usted puede elegir entre el autónomo y la IGS integrada para SAP Web AS 6.40. Desde SAP NetWeaver AS 7,00 sin embargo, sólo la versión integrada de IGS deben ser utilizados. La IGS, básicamente, consta de 3 partes:

Multiplexor (MUX), que administra entrantes / salientes conexiones y distribución de las consultas a los observadores de los puertos apropiados.

Los observadores del puerto, que conectan con el Mux a través de TCP / IP y son la aplicación host para el intérprete de IGS

Los intérpretes, los plug-ins de la IGS, que se encargan de la generación de los gráficos y contenido. Hay varios intérpretes disponibles para diferentes tipos de gráficos y contenidos.

Puede utilizar las siguientes herramientas para administrar el IGS:

Para AS ABAP ABAP: GRAPHICS_IGS_ADMIN de informes o SIGS de transacción, donde se encapsula el informe.

Para AS Java: interfaz de acceso web con la URL http:// (nombre de host): (puerto), mediante el cual el nombre del host es el nombre del equipo en el que la IGS está instalado y el puerto es el puerto de la escucha HTTP.

Si quiere demostrar la IGS en el curso SAPTEC, la cosa más fácil que hacer es llamar a SIGS transacción (o GRAPHICS_IGS_ADMIN informe). En la página de inicio, confirmar el destino sugerido RFC. Esto le llevará a la página inicial de la IGS. Además de los procesos de trabajo, el sistema de ejecución ABAP provee servicios adicionales (estos procesos no trabajan) para la comunicación interna y externa:

Message Server (MS) se encarga de la comunicación entre los despachadores distribuidos dentro de la AS ABAP, lo que permite la escalabilidad de varios servidores de aplicaciones paralelas. El servidor de mensajes se configura una sola vez por el sistema SAP.

El lector gateway (GW) permite la comunicación entre los sistemas SAP, o entre sistemas SAP y los sistemas externos de aplicaciones. Hay uno por cada distribuidor.

El Internet comunication manager (ICM) permite la comunicación con el sistema SAP a través de protocolos web como HTTP. El ICM recibe las solicitudes del cliente y las envía al sistema SAP para su procesamiento. En un ABAP + sistema de Java (ver más abajo), se reconoce si la petición es un llamado a la AS ABAP o el AS Java y delante en consecuencia la solicitud. También se pueden dirigir las peticiones HTTP de un sistema SAP a un servidor Web y enviar la respuesta de vuelta al sistema SAP. Puede configurar un máximo de un proceso de MCI por servidor de aplicaciones (software con sede en la vista).

AS Java Processes

Figure 30: AS Java Processes Los siguientes procesos existen en AS Java:

El dispatcher distribuye las solicitudes entrantes a los procesos del servidor.

El proceso del servidor se ejecuta las aplicaciones Java. Cada proceso de servidor es multi-hilo y por lo tanto puede procesar un gran número de peticiones en paralelo (en contraste con los procesos de trabajo ABAP). Para cada distribuidor hay por lo menos uno los procesos del servidor y puede haber hasta 16 procesos del servidor.

El servicio de mensajes de Java maneja una lista de los despachadores de Java y los procesos del servidor. Es responsable de la comunicación en el entorno de ejecución Java.

El servicio de puesta en cola de Java gestiona bloqueos lógicos que son fijados por el programa de aplicación Java en ejecución un proceso de servidor. El Software Deployment Manager (SDM) es la herramienta estándar que se usa para

instalar los componentes de software Java en el SAP Web AS Java

Tipos de SAP NetWeaver AS Dependiendo de la aplicación o producto utilizado, diferentes tipos de servidor de aplicaciones se instalan.

Figure 31: Possible Types of SAP NetWeaver AS

Sistema AS ABAP: Completa infraestructura en la que las aplicaciones basadas en ABAP pueden ser desarrollados y utilizados.

AS sistema Java: Completa infraestructura para el desarrollo y el uso de aplicaciones basadas en J2EE.

AS ABAP + sistema de Java: Completa infraestructura en la que las aplicaciones basadas en ABAP y J2EE basadas pueden ser desarrollados y usados. Este sistema sólo debe ser instalado de forma explícita si se requiere la aplicación. Por ejemplo, SAP NetWeaver PI 7.0 o SAP Solution Manager 4.0.

Una de las principales características de la plataforma SAP NetWeaver AS es que las tablas de ABAP, programas y datos de aplicación se almacena en el esquema de la base de datos ABAP mientras que Java se almacena los datos en el esquema de Java. En este caso, el entorno de ejecución ABAP puede acceder al esquema de la base de datos ABAP y el entorno de ejecución Java puede acceder al esquema de Java. En el sistema de ABAP + Java, los entornos de ejecución diferentes se comunican directamente a través del conector SAP Java (JCO). AS ABAP Architecture

En AS ABAP, la instancia central se distingue por el hecho de que el servidor de mensajes y el proceso de trabajo en cola a cabo allí. Un servidor de aplicación puede tener varios roles, por ejemplo, como un servidor de diálogo y, simultáneamente, como un servidor de actualizaciones, si proporciona varios procesos de trabajo de diálogo y al menos un proceso de actualización de trabajo.

Nota: Una visión general de las instancias como ABAP está disponible en SM51 (in SAP Easy

Access under Tools → Administration → Monitor → System Monitoring→ Servers.

Puede utilizar la transacción SM50 para mostrar una visión general de los procesos de trabajo en la instancia que ha iniciado sesión en, también se puede mostrar este panorama mediante la elección Tools → Administration → Monitor → System Monitoring → Process Overview en el SAP Easy Access screen.

Figure 32: AS ABAP Architecture El servidor de mensajes ABAP proporciona el AS ABAP con un servicio de mensaje central para la comunicación interna (por ejemplo, para el inicio de las actualizaciones, solicitando y eliminando los bloqueos, lo que provocó peticiones de background). El servidor de mensajes también proporciona información sobre lo que las instancias del sistema están disponibles en la actualidad. Los despachadores de ABAP de los servidores de aplicaciones individuales comunican a través del servidor de mensajes ABAP, que se instala una sola vez al sistema SAP. Al iniciar sesión en el AS ABAP utilizando SAP GUI para Windows o la GUI de SAP para Java utilizando los grupos de inicio de sesión, el servidor de mensajes realiza una distribución de la carga de los usuarios a las instancias disponibles. Esta distribución de la carga, que tiene lugar durante el procedimiento de inicio de sesión, también se conoce como el equilibrio de inicio de sesión de carga. Después de la distribución de la carga por el servidor de mensajes, la GUI de SAP se comunica directamente con el distribuidor. El usuario permanece conectado a esta instancia hasta que se cierra la sesión de nuevo. Nota: Una visión general de los usuarios que han iniciado sesión en la instancia a la que también está conectado, está disponible a través de transacciones SM04 (Tools→

Administration → Monitor → System Monitoring→ User Overview).

Si el acceso a la ABAP AB a través de protocolos web como HTTP con el navegador, el Internet Communication Manager (ICM), recibe la solicitud. Esto envía la solicitud al operador de su instancia. Comunicación de otros sistemas SAP a través de Remote Function Call (RFC) es aceptada por el lector de puerta de enlace (GW). AS Java Architecture En AS Java, la instancia central se distingue por el hecho de que el Administrador de implementación de software (SDM) se ejecuta allí. El servicio de centro de servicios de mensajes (MS) y el Servicio de puesta en cola (ES) se ejecutan en la instancia central de los servicios (ejemplo, CS). Todas las demás instancias del sistema se suele denominar instancias de diálogo. Nota: La totalidad del entorno Java (todos los procesos y el esquema de base de datos) también se refiere a un grupo Java, y los procesos individuales (Dispatcher y el servidor) como

nodos del clúster de Java.

Figure 33: AS Java Architecture Análoga a la AS ABAP, el servicio de mensajes del AS Java proporciona un servicio de mensaje central para la comunicación interna. El servicio de mensajes de Java también proporciona la información que las instancias y los ganglios del AS Java están disponibles. Cada nodo del clúster de Java puede comunicarse directamente con el servicio de mensajes. En el AS Javael servicio puesta en cola mantiene bloqueos lógicos. Cada nodo del clúster de Java puede comunicarse directamente con el servicio de puesta en cola. Cuando el AS Java se accede mediante un navegador, el despachador de Java recibe las solicitudes, que luego son procesados por los procesos del servidor. AS ABAP+Java Architecture

Para el AS ABAP + Java (es decir, ABAP y los procesos Java en el mismo sistema SAP, con el ID de un mismo sistema), los principios de la arquitectura se aplicarán también por separado AS ABAP y AS Java. Sin embargo, hay algunas particularidades porque ambos entornos de ejecución están integrados entre sí en este caso. Nota: El AS ABAP + Java se conoce como complemento de la instalación?? porque es posible instalar un AS ABAP y luego complementarlo con la AS Java en un momento posterior en el

tiempo.

Figure 34: AS ABAP+Java Architecture

La instancia central de un AS ABAP + sistema de Java puede ser reconocido por los siguientes procesos: ABAP-MS, el proceso de puesta en cola de trabajo y SDM. Los servicios centrales del entorno de ejecución Java (Java-MS, en Java ES) también están disponibles en el caso de Java central de servicios aquí. Todos los otros casos, generalmente se llaman las instancias de diálogo. Dado que los dos entornos de ejecución son capaces de responder a las solicitudes a través de protocolos de la Web, el Gerente de Comunicación en Internet debe decidir ahora si la solicitud se dirige a la ABAP o el Java Runtime Environment. Se decide, por medio de la URL de la solicitud. En el caso de una solicitud para el entorno de ejecución ABAP, por ejemplo, la llamada de un Dynpro ABAP web, el ICM hacia delante la solicitud al operador ABAP y los procesos de trabajo responde a la solicitud. Si la solicitud es una solicitud para el entorno de ejecución Java, por ejemplo, la llamada de un Java Server Page (JSP), los delanteros ICM la solicitud a la operadora de Java y uno de los procesos del servidor responde a la solicitud. En un sistema de AS ABAP + Java, los datos también se mantiene en los esquemas de bases de datos separadas (pero en la instalación misma base de datos). Es decir, los procesos de trabajo sólo se puede acceder a los datos ABAP y los procesos del servidor sólo se puede acceder a los datos Java. En el intercambio de datos, tanto en entornos de tiempo de ejecución a continuación, se comunican utilizando el SAP Java Connector (JCO). Esta comunicación es necesaria, por ejemplo, si los datos de facturación que se almacenan en el esquema de datos ABAP se supone que se muestran en una interfaz de usuario de Java. El JCo SAP se integra en el AS Java y también se utiliza cuando un AS del sistema Java tiene que comunicarse con un sistema de control remoto AS ABAP.

AS ABAP processes Al finalizar esta lección, usted será capaz de:

Entender cómo funciona AS ABAP

ListtheASABAP describen los procesos y su propósito

Describa cómo las peticiones a AS ABAP se procesan Los usuarios de inicio de sesión a través del servidor de mensajes (ABAP) (balanceo de carga) o de inicio de sesión directamente en el despachador de ABAP, los procesos de trabajo ejecutar las

entradas de usuario.

La tramitación de una solicitud del usuario en el AS ABAP, como se indica en el gráfico, implica

procesos diferentes en las tres capas (presentación, aplicación y la capa de base de datos):

Figure 35: Processing a User Request

Las entradas de la pantalla de un usuario son aceptados por la presentación del programa de SAP

SAP GUI (interfaz gráfica de usuario SAP), convierte a un formato interno y remitido a AS ABAP.

El despachador (ABAP) es el proceso central de la AS ABAP. Gestiona los recursos para las aplicaciones escritas en ABAP en coordinación con el sistema operativo correspondiente. Las

principales tareas de al despachador ABAP incluyen la distribución de las solicitudes a los procesos

de trabajo, la integración de la capa de presentación y la organización de las operaciones de comunicación.

El despachador primero guarda las solicitudes de procesamiento de colas de petición y luego los

procesa de acuerdo a la Primero en entrar, primero en salir principio.

El dispatcher ABAP distribuye las solicitudes una tras otra a los procesos de trabajo disponibles. Los datos son realmente transformados en el proceso de trabajo, aunque el usuario que ha creado la solicitud, mediante la GUI de SAP no siempre se le asigna el mismo proceso de trabajo. No hay ninguna asignación fija de los procesos de trabajo a los usuarios. Para procesar las peticiones del usuario a menudo es necesario para leer datos desde el esquema ABAP de la base de datos o para escribir en él. Para ello, cada proceso de trabajo está conectado directamente al esquema de la base de datos ABAP.

Una vez finalizado el proceso, el resultado del proceso de trabajo se envía a través de Dispatcher de nuevo a la GUI de SAP. La interfaz gráfica de usuario SAP interpreta estos datos y genera la salida de pantalla para el usuario. Los buffers ayudan a acelerar el procesamiento de las solicitudes de los usuarios. Los datos que se leen a menudo, pero rara vez cambia (por ejemplo, programas o datos Personalización de los clientes, tales como las divisas o los códigos de la empresa) se puede guardar como una copia del contenido de la base de datos en la memoria compartida del servidor de aplicaciones. Esto significa que los datos no tienen que ser leída desde la base de datos cada vez que sea necesario, pero puede ser llamado muy rápidamente de la memoria intermedia. Cada instancia tiene sus propios buffers.

Figure 36: Process Flow for Requests

Los procesos de trabajo ejecuta la lógica de proceso de los programas de aplicación. Además de la memoria interna, un proceso de trabajo tiene un controlador de tarea que coordina las acciones dentro de un proceso de trabajo, los procesadores de software y una interfaz de base de datos. El procesador Dynpro ejecuta la lógica de flujo de pantalla del programa de aplicación, las llamadas procesamiento módulos lógicos, y transfiere el contenido del campo de la lógica de procesamiento. La lógica de procesamiento real de los programas de aplicaciones ABAP es ejecutado por el intérprete de ABAP. El procesador de pantalla indica al procesador de ABAP que subprograma necesita ser ejecutada, dependiendo del estado del proceso de la lógica de flujo de pantalla. El proceso de trabajo de diálogo seleccionada por el operador, realiza una votación en el contexto de usuario en primer lugar. Es decir, los datos que contiene el estado de tramitación actual de un programa en ejecución, así como los datos que caracteriza el usuario se da a conocer que el proceso de trabajo. El proceso de trabajo a continuación, procesa la solicitud del usuario, que puede implicar, por ejemplo, solicitando los datos de la base de datos o de los buffers en la memoria compartida. Una vez que el proceso de trabajo de diálogo ha tramitado la etapa de diálogo, el proceso de trabajo devuelve el resultado, tira el contexto de usuario de vuelta a la memoria compartida, y ahora está disponible de nuevo para una solicitud de nuevo usuario en la cola de solicitudes. El resultado es transferido a la GUI de SAP y el usuario ve la pantalla de nuevo.

Database Interface of AS ABAP Sistemas de Gestión de bases de datos relacionales (RDBMS) se utilizan generalmente para manejar grandes conjuntos de datos. Un RDBMS guarda los datos y las relaciones entre los datos en forma de tablas de dos dimensiones. Estos son conocidos por su simplicidad lógica. Los datos, tablas y relaciones entre tablas se definen a nivel de base de datos en el catálogo de base de datos (el diccionario de datos) del RDBMS. En el lenguaje de programación ABAP de SAP, puede utilizar ABAP Abra SQL (SQL = Lenguaje de consulta estructurado, base de datos de lenguaje de consulta) para acceder a los datos de aplicación en la base de datos, independientemente del SGBDR utilizado. La interfaz de base de datos, que es parte de cada proceso de trabajo de AS ABAP, se traduce Open sentencias SQL de ABAP en las declaraciones correspondientes de SQL para la base de datos específico utilizado (SQL Native). Esto permite que los programas ABAP para ser la base de datos independiente.

Nota: ABAP Abra SQL es un lenguaje de consulta de base de datos basado en la norma (ISO) de SQL, que también contiene mejoras que no están incluidos en la norma.

En la interpretación de Open SQL, la interfaz de base de datos de SAP comprueba la sintaxis de estas declaraciones y asegura la utilización óptima de los locales de SAP en el buffers de memoria compartida del servidor de aplicaciones. Los datos que se requiere con frecuencia por las aplicaciones se almacenan en estos tampones para que el sistema no tenga que acceder al servidor de base de datos para leer los datos. En particular, todos los datos técnicos, tales como programas ABAP, pantallas e información de ABAP Diccionario, así como una serie de parámetros de administración de empresas, por lo general permanecen sin cambios en un sistema operativo y por lo tanto ideal para el almacenamiento en búfer.

Figure 37: Database Query Flow

Además, nativas comandos SQL se puede utilizar directamente en ABAP, es decir, sin utilizar los buffers locales y sin la interfaz de base de datos de la interpretación de los comandos. Usted puede hacer esto mediante la inclusión de los comandos en una sentencia EXEC SQL. - END EXEC. Soporte en el programa ABAP. La intérprete ABAP no comprueba la sintaxis de los comandos dentro de este grupo. Si utiliza SQL nativo, ya no se puede mantener la independencia de la plataforma de los programas afectados.

Processing Dialog Requests La ejecución de las solicitudes de diálogo se caracteriza por lo siguiente:

Un paso de diálogo del programa se asigna a un proceso específico de trabajo de diálogo durante la ejecución.

Los pasos de diálogo individuales para un programa que consta de varias pantallas pueden ser ejecutados por diferentes procesos de diálogo de trabajo durante la ejecución del programa. Esto se conoce como multiplexado del proceso de trabajo.

Un proceso de trabajo de diálogo procesa secuencialmente los pasos de diálogo para los distintos usuarios y programas.

Esto se ilustra por la figura siguiente.

Figure 38: Dialog Work Process Multiplexing

Los programas de la aplicación SAP diferenciar entre la interacción del usuario y la lógica de procesamiento. Las acciones de los usuarios son técnicamente cuenta con pantallas, dynpros también llamados (a partir de programas dinámicos), que consisten en una imagen de la pantalla y la lógica de flujo subyacente. El procesador Dynpro del proceso de trabajo ejecuta la lógica de flujo de pantalla del programa de aplicación, las llamadas procesamiento módulos lógicos, y transfiere el contenido del campo de la lógica de procesamiento. La lógica del flujo de la pantalla en sí se divide en PBO (Process antes de la salida), que se tramita ante la imagen de la pantalla se envía, y PAI (Proceso después de la entrada), que se procesa después de una interacción con el usuario en la pantalla. La parte de PAI de un paso de diálogo lógicamente pertenece a la imagen de la pantalla anterior, mientras que la parte PBO lógicamente pertenece a la imagen de la pantalla posterior. La lógica de procesamiento real de los programas ABAP es ejecutado por el intérprete de ABAP. El procesador de pantalla indica al procesador de ABAP que subprograma necesita ser ejecutada, dependiendo del estado del proceso de la lógica de flujo de pantalla. Si, durante una etapa de diálogo, los datos necesitan ser intercambiados con la base de datos o los amortiguadores, a continuación, este intercambio se lleva a cabo a través de la interfaz de base de datos, que permite el acceso a las tablas de bases de datos, programas ABAP o el Diccionario ABAP, entre otras cosas.

Transactional Processing in AS ABAP The Term Transaction Las transacciones se agrupan las unidades de procesamiento para proporcionar unidades específicas. Ellos tienen cuatro características principales. Las letras iniciales de estas características forman el acrónimo ACID.

Atomic

Consistent

Isolated

Durable Atomic: significa que una transacción es completamente satisfactoria o no tiene ningún efecto en

absoluto. Si un sistema orientado a la transacción deja de funcionar, es necesario asegurarse de que los resultados parciales inconsistentes, no se almacenan.

Consistent: significa que los cambios de estado del sistema de que es precisa y consistente en términos de negocio a otro que también es precisa y consistente en términos de negocio.

Isolated significa que los cambios realizados dentro de una transacción sólo pueden ser vistos por

otras transacciones, incluso las que se ejecutan simultáneamente, después de la confirmación

definitiva (“Commit”).

Los resultados de una operación son duraderos porque después de la confirmación final se almacenan permanentemente en la base de datos.

Database Transactions and ABAP Transactions Cada proceso de trabajo está conectado a un interlocutor específico a nivel de base de datos para la duración de una instancia de SAP tiempo de ejecución. Los procesos de trabajo no pueden intercambiar los compañeros de comunicación en tiempo de ejecución. Esta es la razón por un proceso de trabajo sólo puede realizar cambios en la base de datos dentro de transacciones de base de datos. Una base de datos de transacción es, de acuerdo con el principio de ácido, una secuencia no divisible de las operaciones de base de datos, al principio y al final del cual el conjunto de datos sobre la base de datos debe ser consistente. El principio y el final de una transacción de base de datos se definen por un comando commit (“Base de datos de commit“) para el sistema de base de datos. Durante una operación de base de datos (entre dos comandos de confirmación), el sistema de base de datos se asegura que el conjunto de datos es coherente. El sistema de base de datos se toma la tarea de restaurar el conjunto de datos a su estado anterior después de una transacción ha finalizado con un error (“Rollback”). Las transacciones comerciales se agrupan las unidades de procesamiento para proporcionar una función específica, estas unidades de procesamiento de ejecutar cambios en la base de datos que son consistentes y tienen sentido en términos de negocio. Ejemplos típicos son las

actualizaciones de crédito y débito, que sólo tienen sentido en conjunto, o la creación de un orden y la reserva de los materiales pertinentes. En consecuencia, un AS ABAP transacción se define como un proceso de negocio no divisible que, o bien debe ser ejecutada por completo o no en absoluto. AS ABAP transacciones se implementan como secuencias de pasos de diálogo relacionados lógicamente que sean compatibles en términos de negocio. Cada paso de diálogo de usuario está representado por una imagen de la pantalla.

Figure 39: Relationship between database transactions and SAP transactions

Transacciones de SAP no son necesariamente ejecutados en un solo proceso de trabajo de diálogo. Dentro de una operación que cambia los datos de la base de datos, las peticiones de los usuarios los cambios de base de datos que utilizan las pantallas individuales que se muestran. Una vez que se complete la transacción, los cambios deben dar lugar a un estado de base de datos consistente. Los pasos de diálogo individuales pueden ser procesados por los procesos de trabajo diferentes (proceso de trabajo de multiplexación), y cada proceso de trabajo secuencialmente maneja pasos de diálogo para aplicaciones no relacionadas. Aplicaciones cuyo diálogo pasos son ejecutadas por el mismo proceso un trabajo después de que el otro no puede funcionar dentro de la transacción misma base de datos si no están relacionados entre sí. Por lo tanto, un proceso de trabajo debe iniciar una transacción nueva base de datos para cada etapa de diálogo. La relación entre las transacciones de bases de datos y transacciones de SAP se ilustra en la gráfica de la relación “Entre las transacciones de bases de datos y transacciones de SAP”.

Lock Management Para garantizar la coherencia de datos dentro de un sistema SAP, debe asegurarse de que los registros de datos no se puede acceder y cambiar más de un usuario en cualquier momento. Para ello, el sistema SAP tiene su propio concepto de gestión de la cerradura. Desde una perspectiva de base de datos, cada paso de diálogo constituye una unidad física y lógica: la transacción de base de datos. La administración de bloqueo de base de datos solo puede coordinar este tipo de transacciones de base de datos. Desde un punto de vista de SAP, sin embargo, esto no es suficiente, porque las transacciones de SAP, que están formados a

partir de una secuencia de pasos de trabajo lógicamente relacionados que son consistentes en términos de negocios, generalmente se componen de varios pasos de diálogo. Los sistemas de SAP necesitan tener su propio candado de gestión. Esto se realiza mediante el proceso de trabajo en cola. Esto asegura también que la plataforma a la independencia de la gestión de bloqueo se mantiene. El concepto de bloqueo SAP trabaja en el principio de que los programas de SAP que las entradas de cierre de los registros de datos a ser procesados en una tabla de bloqueos. Las entradas de bloqueo sólo se puede hacer si no existen ya para las entradas de la tabla sean bloqueados. El proceso de trabajo en cola administra el bloqueo de lógica de las operaciones de SAP en la tabla de bloqueos. La tabla de bloqueo se encuentra en la memoria principal de la instancia en el proceso de trabajo en cola.

Nota: El ejemplo que tiene como principal memoria contiene la tabla de bloqueo es también conocido como el servidor en cola.

Figure 40: Lock Management in AS ABAP

Si un usuario desea cambiar el acceso a los datos, las solicitudes de diálogo de ejecución de procesos de trabajo con un candado (para ello, el desarrollador de aplicaciones debe programar esta petición de forma explícita). Cuando un objeto de bloqueo se activa correctamente en el Diccionario ABAP, el sistema genera un módulo de función enqueue y un módulo de función DEQUEUE con el nombre respectivo:

ENQUEUE_<Sperrobjektname>

DEQUEUE_<Sperrobjektname>

El desarrollador utiliza estos módulos de función en el programa de aplicación para solicitar

Si una solicitud de diálogo se procesa en el servidor en cola, el proceso de trabajo de diálogo se puede acceder directamente a la tabla de bloqueos. Ahora comprueba si una nueva cerradura puede ser generada, es decir, si hay una colisión con las cerraduras que ya han sido fijados. Si el bloqueo se puede configurar, el proceso de trabajo de diálogo que crea y el usuario (propietario del bloqueo) se le da la llave de la cerradura. La tecla de bloqueo se mantiene en el contexto de usuario en la memoria compartida. Si el proceso de trabajo de diálogo que se procesa la solicitud del usuario y el proceso de trabajo en cola no se están ejecutando en la misma instancia, estos dos procesos de trabajo se comunican a través del servidor de mensajes. En este caso, la solicitud de bloqueo se envía desde el proceso de trabajo de diálogo para el proceso de trabajo en cola a través de los despachadores y el servidor de mensajes. El proceso de trabajo en cola ahora comprueba si un bloqueo se puede configurar. Si esto es posible, el bloqueo se establece por el proceso de trabajo en cola, y la tecla de bloqueo transferido al proceso de diálogo solicitando trabajo a través del distribuidor y servidor de mensajes. Cuando el bloqueo se solicita, el sistema comprueba si los solicitados conflictos de bloqueo con las entradas existentes en la tabla de bloqueos. Si la tabla de bloqueos ya contiene las entradas correspondientes, la solicitud de bloqueo es rechazada. El programa de aplicación puede informar al usuario de que la operación solicitada no se puede ejecutar en la actualidad. El desarrollador de aplicaciones puede elegir entre diferentes modos de bloqueo:

Escribir bloqueos (el modo de bloqueo exclusivo), los datos de bloqueo puede ser editado por un solo usuario. Las solicitudes de otro bloqueo de escritura y otro bloqueo de lectura son rechazados. Un bloqueo de escritura rotects los objetos bloqueados en contra de todo tipo de otras transacciones. Sólo el propietario del bloqueo mismo se puede establecer el bloqueo de nuevo (acumular).

Los bloqueos de lectura (bloqueo de modo compartido), varios usuarios pueden tener acceso de lectura a los datos cerrados al mismo tiempo. Las solicitudes de bloqueos de lectura adicionales son aceptados, incluso si son de otros usuarios. Un bloqueo de escritura es rechazado.

Escritura mejorado de bloqueos (bloqueo no acumulativo modo exclusivo), mientras que bloqueos de escritura puede ser sucesivamente solicitado y publicado por la misma transacción, un bloqueo de escritura reforzada sólo se puede solicitar una vez, incluso por la misma transacción. Todas las demás solicitudes para las cerraduras son rechazados.

Bloqueos optimistas (el modo de bloqueo optimista); bloqueos optimistas responden como bloqueo de lectura en un primer momento y se pueden cambiar bloqueos para escribir. Un bloqueo optimista se activa si el usuario muestra los datos en el modo de cambio. Bloqueos optimistas sobre el mismo objeto no colisionan. Si el usuario desea guardar los datos (cambio), el bloqueo optimista se debe cambiar a un bloqueo de escritura (modo S). (Se produce un error si alguien no se establece un bloqueo optimista sobre el objeto antes.) Otros bloqueos optimistas sobre el objeto se eliminan en el proceso.

Establecimiento de bloqueos con un programa de aplicación son puestos en libertad por el mismo programa de aplicación o por el programa de actualización una vez que la base de datos ha sido modificada. Los bloqueos que se han pasado a un proceso de trabajo de actualización de esta manera también se escriben en un archivo a nivel de sistema operativo y por lo tanto, puede ser restaurado si el servidor se cae en cola. Transaction SM12 (Tools → Administration → Monitor→ Lock Entries) muestra los bloqueos que están establecidas actualmente. Si el bloqueo ya ha sido heredado con el proceso de actualización, la bandera de copia de seguridad también se ha establecido. Tal bloqueo también se incluye en la tabla de bloqueo de nuevo después de reiniciar el servidor en cola. Hay básicamente dos maneras de eliminar bloqueos de los usuarios:

Poner fin a la sesión del usuario en la información general del usuario (transaction SM04 or Tools → Administration → Monitor → System Monitoring → User Overview).

Eliminar manualmente las entradas de bloqueo en la SM12. El primer método (que finaliza la sesión del usuario) también se traduce en el propietario del bloqueo original, dejando a la transacción y por lo tanto la liberación de todos los bloqueos, el segundo método (eliminar manualmente usando SM12) simplemente elimina la entrada de bloqueo de la tabla de bloqueos. En teoría, esto permite a varios usuarios para cambiar los registros de datos simultáneamente.

Precaución: Antes de eliminar bloqueos utilizando la transacción sm04, los administradores del sistema debe comprobar primero si el usuario que posee el bloqueo se sigue registrando en el sistema. Sólo debe eliminar las entradas de bloqueo con la transacción SM12, si el

propietario del bloqueo ya no es iniciado sesión en el sistema, pero todavía posee el bloqueo (por ejemplo, si la conexión entre la interfaz gráfica de usuario SAP y el sistema SAP se ha roto debido a que el usuario ha desactivado la o su equipo front-end sin cerrar la sesión en el sistema).

Standalone Enqueue Server / ABAP Central Services Por razones de alta disponibilidad, el proceso de trabajo en cola, junto con el servidor de mensajes ABAP también se puede extraer de la instancia central y se instala como una instancia central de los servicios de ABAP (ASCS). Ir a la Biblioteca de la plataforma SAP NetWeaver para

obtener más detalles: SAP NetWeaver by Key Capability→ Application Platform by Key

Capability → ABAP Technology → Client/Server Technology → The SAP Lock Concept

(BC-CST-EQ) → Standalone Enqueue Server.

Update En el sistema SAP, un proceso de negocio se asignan mediante una transacción de SAP que puede contener varios cambios en la pantalla (por ejemplo, la creación de un orden). Los cambios de datos efectuados por este proceso se supone que se ejecuta totalmente o nada en absoluto en la base de datos. Si la operación se termina durante la transacción o se produce un error, la transacción no se supone que debe hacer los cambios de base de datos en absoluto. El sistema SAP de actualización, que se describe a continuación, se encarga de esto.

El sistema de actualización también ofrece mayor seguridad, rendimiento y restaurabilidad en la ejecución de los cambios de base de datos.

Figure 41: The principle of asynchronous updates

El sistema de actualización es una tecnología que permite que las transacciones de SAP fuera de la carga de base de datos cambien intensivos de tiempo. Éstos entonces se lleva a cabo de forma asincrónica en los procesos de actualización especiales de trabajo. También evita los problemas de espalda rollo-causadas por la diferencia en la concepción de la unidad lógica de trabajo (LUW) en una transacción de SAP y en la base de datos. Si durante un proceso de trabajo de diálogo, los datos almacenados temporalmente para su procesamiento se pasa a un proceso de trabajo de actualización para su posterior procesamiento, el proceso de trabajo de diálogo no espera a que la solicitud de actualización a realizar: la actualización de forma asíncrona (no simultánea). El proceso de actualización asíncrona se ilustra en el gráfico “El principio de actualizaciones asincrónicas”. La parte de diálogo se completa con el comando COMMIT WORK ABAP, la parte de actualización de la transacción se inicia: el servidor de actualizaciones transfiere la solicitud de actualización a un proceso de trabajo de actualización. Aquí, cada paso de diálogo corresponde a una transacción de base de datos (que se ejecuta ya sea completamente o en absoluto en la base de datos y se completó con un comando COMMIT). La parte de actualización de la transacción SAP se ejecuta en una transacción de base de datos. Es sólo entonces que los datos se copian en las tablas de aplicación.

Figure 42: The asynchronous update process

Si los usuarios desean cambiar de un registro de datos en una transacción de SAP, que ellos llaman la transacción correspondiente en el cuadro de diálogo, hacer que las entradas correspondientes en las pantallas y luego iniciar el proceso de actualización de guardar los datos. Este proceso desencadena los siguientes pasos:

1. El programa bloquea el registro de datos para otros usuarios. El programa hace esto al abordar el proceso de trabajo en cola (utilizando el servidor de mensajes en su caso). El proceso de trabajo en cola hace que la entrada correspondiente en la tabla de bloqueos o (si otro usuario ya ha cerrado los datos) informa al usuario que el registro de datos que actualmente no se puede cambiar.

2. Si el proceso de trabajo en cola logrado escribir la entrada de bloqueo para la tabla de bloqueos, que pasa a la tecla de bloqueo que creó para el usuario, el programa lee el registro que se cambia la base de datos y el usuario puede cambiar el registro en la imagen de la pantalla del la transacción SAP.

3. En el proceso de diálogo de trabajo activo, el programa llama a un módulo de función utilizando CALL FUNCTION... IN UPDATE TASK y escribe la solicitud de cambio de tablas de actualización de bases de datos. Éstos también se llaman VB * Las tablas, debido a que sus nombres empiezan con “VB”. Actúan como memoria temporal y almacenar los datos que han de cambiarse hasta que pueda ser recogido y se escriben en las tablas de aplicación en la base de datos (en una operación única base de datos).

4. Al final de la parte de diálogo de la transacción (por ejemplo, cuando el usuario guarda los datos posiblemente, después de completar otras medidas de diálogo), el programa inicia el cierre de la transacción con la sentencia COMMIT WORK. El proceso de trabajo que se encarga de la etapa de diálogo activo completa la cabecera de actualización y desencadena un proceso de trabajo de actualización.

5. Sobre la base de la información (clave de la orden de actualización, bloqueo del teclado) transferidos desde el proceso de trabajo de diálogo, el proceso de trabajo de actualización lee los registros que pertenecen a esta transacción SAP de las tablas VB.

6. El proceso de trabajo de actualización transfiere los cambios marcados y recogidos en las tablas VB* a la base de datos como una solicitud de cambio y evalúa la respuesta de la base de datos. Si los cambios fueron escritos con éxito a las tablas de destino, el

proceso de trabajo de actualización de base de datos activa un commit después de la última modificación de la base de datos y elimina las entradas de las tablas VB *.

7. Las entradas de bloqueo en la tabla de bloqueos se restablecen.

Nota: El programador de aplicaciones decide si y cómo utilizar las actualizaciones asíncronas en la programación de la transacción. Además de la actualización asíncrona, hay algunas técnicas de actualización de otros (por ejemplo, síncrono o local).

Para aumentar el rendimiento aún más, los desarrolladores de aplicaciones pueden configurar diferentes tipos de actualizaciones:

tiempo crítico, primarias actualizaciones V1. Ellos son relevantes para los objetos que tienen una función de control en el sistema SAP, tales como un cambio en el stock de material o una creación de la orden.

tiempo no crítico, actualizaciones secundarias V2 que dependen de las actualizaciones de V1. Estos son, por ejemplo, las actualizaciones puramente estadísticas como el cálculo de los resultados.

no tiempo crítico las actualizaciones que se recogidos y tratados en un momento posterior en el tiempo (plazo colectiva).

Los módulos de V1 para una transacción de SAP se procesan de forma secuencial en un proceso de actualización sola obra. Si su sistema SAP tiene un proceso de trabajo para las actualizaciones V2 (UP2 tipo), a continuación, los módulos V2 sólo se actualizará allí. De trabajo V1 libera los bloqueos pertinentes una vez más. Esto significa que el”Normales” actualizar los procesos de trabajo volverán a estar disponibles más rápidamente para el tiempo las actualizaciones críticas de V1, y que las entradas de bloqueo correspondientes se eliminan antes. Si usted no ha configurado todos los procesos de actualización V2 de trabajo, entonces el proceso de trabajo V1 se encarga de todas las actualizaciones. En el largo colectivo, los módulos no se actualizan automáticamente, pero sólo cuando un informe especial (informe RSM13005) desencadena la actualización. Todas las llamadas de los módulos de función se recogen a continuación, agregar y actualizar a la vez. Al hacerlo, se manejan como los módulos de actualización de V2. Si ocurre un error durante una actualización, entonces el procesamiento del componente de actualización activa termina. Los usuarios pueden recibir automáticamente una notificación por correo expreso, cuando finaliza la actualización. Si un proceso de trabajo de diálogo termina, mientras que la escritura de datos en las tablas *VB, las tablas contienen datos que no se actualizarán. Estas entradas pueden ser automáticamente eliminadas la próxima vez que inicie el sistema o pueden ser eliminados manualmente. Las tablas de aplicación permanecen sin cambios. Una actualización asíncrona puede terminar por una variedad de razones. Si, por ejemplo, varios intentos se hacen para entrar en el registro de datos misma (con Insertar)) en una tabla, lo que desencadena la condición de excepción “Clave duplicada” en la codificación, porque ya existe una entrada en la tabla en esta clave. Por lo tanto, el registro de datos correspondiente no se puede escribir en la tabla de base de datos más de una vez.

Cuando termina una actualización, el sistema envía un correo rápido al usuario que haya activado la actualización. Cualquier medida adicionales deben ser llevadas a cabo por el administrador del sistema. Transacción SM13 (solicitudes de actualización) proporciona a los administradores de sistemas con herramientas de análisis para manejar las actualizaciones terminadas. Una vez que el error que causó la extinción se ha corregido (por ejemplo, daños en el hardware reparado), el usuario final debe reiniciar el proceso.

Print Los sistemas de SAP ofrecen una amplia variedad de opciones para la representación de las empresas y otros datos. Estos datos, creados y formateados en una etapa de diálogo, se pueden enviar a las impresoras y otras interfaces de salida (fax, correo electrónico, y así sucesivamente). Una impresora primero se debe configurar en el sistema antes de que pueda ser abordado. Usted puede seleccionar una impresora que ya ha sido creado por la elección del icono de impresión (Ctrl + P), a continuación, utilizando la ayuda F4. Una impresora estándar normalmente se establece de forma predeterminada en su perfil de usuario. Una vez que la impresora se ha configurado, el sistema SAP tiene toda la información que necesita para ser capaz de crear una orden SPOOL. La solicitud spool contiene información sobre los datos que vaya a emitir, su formato, y el modelo de impresora utilizado. La solicitud spool generada se almacena en la TemSe (archivo secuencial temporal).

Sugerencia: las peticiones de la cola pueden ser creadas por los procesos de trabajo de diálogo, o por los procesos de trabajo de background. Los procesos de la cola de trabajo no crean peticiones spool.

Figure 43: Printing in AS ABAP

Como se puede ver en el gráfico de procesamiento de cola de impresión en un sistema SAP, unos formatos de trabajo spool de proceso de los datos especificados en la solicitud del carrete y crea un Equest salida. La solicitud de salida contiene todos los datos en un formato apropiado para la impresora. Estos datos pueden ser transmitidos a un sistema adecuado proceso de

funcionamiento spool a nivel local (en el mismo equipo) o remota (mediante una conexión de red). Nota: En un sistema SAP, la conexión entre un proceso de trabajo spool y el proceso del sistema operativo spool es conocido como el método de acceso. Hay más métodos de acceso que se muestran más arriba. Estos son los dos más comúnmente utilizados los métodos de acceso para la conexión de impresoras con los sistemas SAP. En este contexto, local o remoto no se refieren a la ubicación física de la producción, sino al lugar donde el proceso de trabajo es spool “Conectado” al sistema de proceso de operación de carrete. Para el procesamiento de impresión, el mejor rendimiento se consigue mediante el envío de los datos a imprimir en el sistema operativo tan pronto como sea posible. Para ello, utilice el método de acceso local. El sistema operativo realiza todas las tareas pendientes, como la cola de espera y transferencia de datos a la impresora seleccionada. Sugerencia: Uno de los requisitos de menor importancia, pero indispensable para la impresión de los sistemas de SAP es que cada impresora seleccionable permite la impresión a nivel de sistema operativo. Usted puede mostrar su propio spool, y pide la salida a través de System → Own Spool Requests (transaction SP02). Via System → User Profile→ Own Datos (código de transacción SU3) se puede especificar la configuración personal para la impresión en la página de ficha Valores predeterminados en la sección Spool Control.

Background processing Procesamiento de SAP de background es un método para automatizar tareas rutinarias y para optimizar el uso de su organización de SAP los recursos informáticos. En el proceso de background, se indica al sistema R / 3 para ejecutar programas para usted. Usted puede utilizar el proceso de background para ejecutar programas intensivos de larga duración o el recurso al fuera de las horas pico. Se puede utilizar para asignar el sistema de la tarea para ejecutar informes y programas. No hay tensión en los recursos de diálogo y los informes que se ejecutan en el background no están sujetos a las restricciones de tiempo de ejecución de la elaboración de diálogo (la terminación del programa después de un tiempo de ejecución de diez minutos). La segregación de procesamiento en segundo plano a los procesos especiales de trabajo le da una dimensión adicional para separar el proceso de background y el trabajo interactivo. Normalmente, el proceso de background y el trabajo interactivo en el sistema llevará a cabo en diferentes momentos. Por ejemplo, el sistema se utiliza de forma interactiva durante el día y el proceso de background se lleva a cabo por la noche. Usted puede utilizar procesos en segundo plano el trabajo de separar el proceso de background y el trabajo interactivo también por los servidores porque los trabajos de background sólo se ejecutan en los servidores que ofrecen el proceso de background.

Figure 44: Scheduling Background Tasks (Jobs)

El usuario final usualmente se puede programar el programa que se comenzó en el background como un trabajo desde la transacción de la aplicación. El trabajo entonces “Espera” para el tiempo de ejecución previsto en la tabla de planificación de tareas. Si el tiempo ha llegado y los procesos de trabajo libres de antecedentes están disponibles, el trabajo se distribuye a un proceso de trabajo de background por el planificador de background y luego ejecutados. El usuario puede visualizar el resultado en la transacción de aplicación o, en el caso de los programas de generación de la lista, mira a la solicitud de spool perteneciente a su trabajo (véase la sección de impresión). Para mostrar sus propios puestos de trabajo, elija Sistema → Jobs propios (código de transacción SMX). La administración del sistema y la preparación del trabajo tienen acceso a una herramienta para

la programación de los diferentes tipos de background toma con la operación SM36 (Tools →CCMS → Background Processing→ Define Jobs). El monitoreo de todo el sistema de

puestos de trabajo se lleva a cabo con la transacción SM37 (Tools → CCMS→Background Processing→ Jobs - Overview and Administration).

Para la programación entre sistemas y el seguimiento de las tareas de background, puede usar SAP Central Process Scheduling (SAP CPS) y otros productos de los socios autorizados.

Communication via the Gateway Cada instancia de un sistema AB ABABP contiene una puerta de enlace. Se utiliza para la comunicación entre los procesos de trabajo de diferentes instancias o sistemas de SAP, así como los procesos de trabajo y programas externos. El lector gateway (por lo general acaba de llamar gateway) es el proceso principal del sistema de puerta de enlace. El dispatcher se inicia y comprueba periódicamente.

Figure 45: Gateway Communication

En la comunicación entre las instancias de un sistema o sistemas utilizando Remote Function Call (RFC) o CPIC, el gatwey está siempre involucrado. Si un proceso de trabajo de diálogo tiene que establecer una conexión RFC a un sistema remoto en el contexto de una petición, por ejemplo, para recuperar los datos del cliente, se utiliza la puerta de entrada, que a continuación se hace cargo de la comunicación con el sistema remoto. El gateway envía la solicitud del gatwey del sistema remoto. El gateway remoto transfiere la solicitud al dispatcher. Esto a su vez envía la solicitud a uno de sus procesos de trabajo, que la comunica directamente con “su” gatwey. Conexión de entrada de RFC, por lo tanto siempre se recibe por la puerta de enlace. Las conexiones salientes son iniciadas por el proceso de trabajo.

Processing Web Requests Solicitudes web son recibidas por el Internet Communication Manager (ICM). Estos HTTP (S) solicitudes se pueden procesar, ya sea en el proceso de trabajo ABAP (por ejemplo, las aplicaciones Web Dynpro ABAP) o remitido a AS Java en un sistema AS ABAP + Java (por ejemplo, Java Web Dynpro aplicaciones). El ICM se puede utilizar la dirección URL para decidir a donde se envía la solicitud (si no puede responder a la solicitud de su caché).

Figure 46: Processing a Web Request

Si la solicitud es para el entorno de ejecución Java, se envía al distribuidor de Java (2b), que a su vez lo reenvía a un proceso de servidor Java (3b). Si la solicitud es el entorno de ejecución ABAP, el ICM se remite al despachador ABAP (2a), el cual se maneja como una típica petición de SAP GUI (ver sección anterior). El proceso de trabajo que procesa la consulta ahora se comunica directamente con el ICM (4a). El ICM devuelve la respuesta al usuario que envió la solicitud (5).