Está en la página 1de 28

Unit 3

The System Kernel


Objetivos de la Unidad. Despus 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 trmino instancia y reconocer las caractersticas de una instancia central Entender cmo funciona AS ABAP Una lista de los procesos de AS ABAP y describir su propsito Describa cmo las peticiones a AS ABAP se procesan

Introduccin. 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 ejecucin diferentes: un entorno de ejecucin ABAP (tipo de uso AS ABAP) y Java Runtime Environment (tipo de uso como Java). ABAP (Advanced Business Application Programming) es un lenguaje de programacin desarrollado por SAP. Muchas aplicaciones de negocio de un sistema SAP estn 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 estndar. De este modo, toda la infraestructura, poderosa del AS ABAP se puede utilizar, que tambin apoya la creacin de las aplicaciones ms complejas por parte de grandes grupos de desarrolladores. El Servidor de aplicaciones de ABAP ofrece el entorno de ejecucin para programas escritos en ABAP.

SAP no slo proporciona un entorno de ejecucin de programas ABAP, sino tambin un entorno de ejecucin de los programas de Java. AS Java es un servidor de aplicaciones de acuerdo con el Java 2 Enterprise Edition (J2EE) estndar. El lenguaje de programacin Java fue introducido por primera vez por Sun Microsystems, Inc. en 1995. Java es un lenguaje de programacin 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 clsicas de los applets utilizados en pginas web a las aplicaciones cliente / servidor. Java 2 Platform Enterprise Edition (J2EE) es un estndar del proveedor para una gran variedad de componentes de software que esencialmente tienen origen en el lenguaje de programacin

Java. Sun utiliza la prueba de compatibilidad J2EE para asegurar que las especificaciones de Java 2 Enterprise Edition se observen. De acuerdo con la especificacin J2EE de la lgica de la aplicacin se empaqueta en Enterprise Java Beans (EJB). Que representan los componentes de programa de Java. Un contenedor implcito proporciona los componentes con los servicios del entorno de ejecucin. 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 bsicamente dos maneras de hacer esto. En el punto de vista orientado a hardware, el trmino 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 estn 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 tambin pueden ser servidores de otros servicios especficos. 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 trminos 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 aplicacin de software de operacin de negocios: los procesos de presentacin (por ejemplo, para desplegar pantallas). Los procesos de aplicacin (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 cmo se van a distribuir los procesos necesarios entre el hardware disponible. Hay varias maneras de hacer esto, algunos de los cuales se describen detalladamente ms adelante. Las configuraciones son ya sea de un solo nivel o de varios niveles, dependiendo del nmero de capas de hardware utilizados (vase el grfico siguiente). El sistema SAP ECC es un ejemplo de software de aplicacin empresarial. En configuraciones de un solo nivel, todas las tareas de procesamiento (procesos de base de datos, aplicacin y presentacin) son realizadas por un equipo. Esto es clsico de tratamiento en ordenador central. Configuraciones de dos niveles se implementan normalmente el uso de servidores especiales de presentacin que son responsables exclusivamente para el formato de la interfaz grfica. En una configuracin 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 porttil). 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 implementacin de los niveles adicionales de hardware (por ejemplo, mover los procesos de presentacin a otras mquinas). (two-tier) La configuracin de dos niveles con los procesos de presentacin distribuidos (como se muestra en el grfico anterior) se puede mantener un buen rendimiento para un nmero significativamente mayor de usuarios, sin aumentar sustancialmente los costes de hardware. La carga resultante de los procesos de presentacin se distribuye a los diversos frontales ordenadores y as no influye en el rendimiento de la mquina de base de datos. Sin embargo, si el nmero de usuarios supera un cierto lmite superior, el sistema central, en el que tanto los procesos de aplicacin 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 distribucin de los procesos de la capa de aplicacin a varios equipos. Otra de las

ventajas de aadir una capa de hardware especficamente para los procesos de aplicacin es que facilita la escalabilidad. Si el nmero de usuarios de SAP en un sistema aumenta con el tiempo, afectando negativamente el rendimiento del sistema, a continuacin, este problema puede, en la mayora de los casos, ser resuelto simplemente mediante la adicin de otro host para los procesos. Una alternativa de dos niveles (two-tier) de configuracin es la instalacin de potentes sistemas de escritorio y que los utilicen para la presentacin 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 administracin adicional. En el entorno de SAP Business Suite, ms complejas de cliente / servidor que consiste en configuraciones de ms de tres pisos son tericamente posible y en la prctica. Un nivel adicional podra 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 ms servicios. Los servicios prestados por una instancia se inician o se detiene junto. Se utiliza un perfil de instancia comn para establecer los parmetros de todos los componentes de una instancia. Cada instancia tiene sus propias reas de amortiguamiento. Una instancia se ejecuta en un equipo fsico, pero no puede haber varias instancias en un solo ordenador. Una instancia se ejecuta en un equipo fsico, pero no puede haber varias instancias en un solo ordenador. Un instancia es identificado por el ID del sistema (SID) y el nmero de instancia. Sugerencia: Los trminos (SAP) de la instancia y servidor de aplicaciones se utilizan a menudo como sinnimos.

Figure 28: Instances of an SAP System (Example) Cuando se instala un sistema SAP, ya tienes la opcin de separar los procesos a nivel de aplicacin 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 fsico 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 identificacin (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 ms abajo). Para el AS ABAP, estos servicios tambin 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 dems instancias del sistema se suele denominar instancias de dilogo. Si la instancia central y la base de datos (y para el AS Java tambin la instancia de servicios centrales) estn instaladas en el mismo equipo, esto se conoce como un sistema central. Processes of the SAP NetWeaver Application Server El sistema SAP tiempo de ejecucin se compone de un gran nmero de procesos paralelos que trabajan juntos. Aqu, se puede distinguir entre el entorno de ejecucin de ABAP (AS ABAP) y el entorno de ejecucin 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 nmero de procesos de trabajo en funcin de los recursos de hardware: El dispatcher distribuye las solicitudes a los procesos de trabajo. Procesos de dilogo de trabajo (Dialog work process) cumplen todas las solicitudes para la ejecucin de pasos de dilogo 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 ms de un proceso de trabajo de impresin para cada distribuidor. Update work process ejecuta las solicitudes de actualizacin. Al igual que en los procesos de trabajo spool, usted necesita por lo menos un proceso de trabajo de actualizacin por el sistema SAP, y se puede configurar ms 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 ms 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 lgicos del entorno de ejecucin ABAP de SAP. Slo 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 grficos en un navegador de Internet con un mnimo esfuerzo. El IGS est integrado en las diferentes tecnologas 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 grfica y no grfica. 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 instalacin (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 autnomo y la IGS integrada para SAP Web AS 6.40. Desde SAP NetWeaver AS 7,00 sin embargo, slo la versin integrada de IGS deben ser utilizados. La IGS, bsicamente, consta de 3 partes: Multiplexor (MUX), que administra entrantes / salientes conexiones y distribucin de las consultas a los observadores de los puertos apropiados. Los observadores del puerto, que conectan con el Mux a travs de TCP / IP y son la aplicacin host para el intrprete de IGS Los intrpretes, los plug-ins de la IGS, que se encargan de la generacin de los grficos y contenido. Hay varios intrpretes disponibles para diferentes tipos de grficos y contenidos.

Puede utilizar las siguientes herramientas para administrar el IGS: Para AS ABAP ABAP: GRAPHICS_IGS_ADMIN de informes o SIGS de transaccin, 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 ms fcil que hacer es llamar a SIGS transaccin (o GRAPHICS_IGS_ADMIN informe). En la pgina de inicio, confirmar el destino sugerido RFC. Esto le llevar a la pgina inicial de la IGS. Adems de los procesos de trabajo, el sistema de ejecucin ABAP provee servicios adicionales (estos procesos no trabajan) para la comunicacin interna y externa: Message Server (MS) se encarga de la comunicacin 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 comunicacin 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 comunicacin con el sistema SAP a travs de protocolos web como HTTP. El ICM recibe las solicitudes del cliente y las enva al sistema SAP para su procesamiento. En un ABAP + sistema de Java (ver ms abajo), se reconoce si la peticin es un llamado a la AS ABAP o el AS Java y delante en consecuencia la solicitud. Tambin 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 mximo 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 nmero 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 comunicacin en el entorno de ejecucin Java. El servicio de puesta en cola de Java gestiona bloqueos lgicos que son fijados por el programa de aplicacin Java en ejecucin un proceso de servidor. El Software Deployment Manager (SDM) es la herramienta estndar que se usa para instalar los componentes de software Java en el SAP Web AS Java

Tipos de SAP NetWeaver AS Dependiendo de la aplicacin 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 slo debe ser instalado de forma explcita si se requiere la aplicacin. Por ejemplo, SAP NetWeaver PI 7.0 o SAP Solution Manager 4.0.

Una de las principales caractersticas de la plataforma SAP NetWeaver AS es que las tablas de ABAP, programas y datos de aplicacin 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 ejecucin ABAP puede acceder al esquema de la base de datos ABAP y el entorno de ejecucin Java puede acceder al esquema de Java. En el sistema de ABAP + Java, los entornos de ejecucin diferentes se comunican directamente a travs 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 aplicacin puede tener varios roles, por ejemplo, como un servidor de dilogo y, simultneamente, como un servidor de actualizaciones, si proporciona varios procesos de trabajo de dilogo y al menos un proceso de actualizacin de trabajo. Nota: Una visin general de las instancias como ABAP est disponible en SM51 (in SAP Easy Access under Tools Administration Monitor System Monitoring Servers. Puede utilizar la transaccin SM50 para mostrar una visin general de los procesos de trabajo en la instancia que ha iniciado sesin en, tambin se puede mostrar este panorama mediante la eleccin 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 comunicacin interna (por ejemplo, para el inicio de las actualizaciones, solicitando y eliminando los bloqueos, lo que provoc peticiones de background). El servidor de mensajes tambin proporciona informacin sobre lo que las instancias del sistema estn disponibles en la actualidad. Los despachadores de ABAP de los servidores de aplicaciones individuales comunican a travs del servidor de mensajes ABAP, que se instala una sola vez al sistema SAP. Al iniciar sesin en el AS ABAP utilizando SAP GUI para Windows o la GUI de SAP para Java utilizando los grupos de inicio de sesin, el servidor de mensajes realiza una distribucin de la carga de los usuarios a las instancias disponibles. Esta distribucin de la carga, que tiene lugar durante el procedimiento de inicio de sesin, tambin se conoce como el equilibrio de inicio de sesin de carga. Despus de la distribucin 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 sesin de nuevo. Nota: Una visin general de los usuarios que han iniciado sesin en la instancia a la que tambin est conectado, est disponible a travs de transacciones SM04 (Tools Administration Monitor System Monitoring User Overview).

Si el acceso a la ABAP AB a travs de protocolos web como HTTP con el navegador, el Internet Communication Manager (ICM), recibe la solicitud. Esto enva la solicitud al operador de su instancia. Comunicacin de otros sistemas SAP a travs 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 implementacin 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 dems instancias del sistema se suele denominar instancias de dilogo. Nota: La totalidad del entorno Java (todos los procesos y el esquema de base de datos) tambin se refiere a un grupo Java, y los procesos individuales (Dispatcher y el servidor) como nodos del clster de Java.

Figure 33: AS Java Architecture Anloga a la AS ABAP, el servicio de mensajes del AS Java proporciona un servicio de mensaje central para la comunicacin interna. El servicio de mensajes de Java tambin proporciona la informacin que las instancias y los ganglios del AS Java estn disponibles. Cada nodo del clster de Java puede comunicarse directamente con el servicio de mensajes. En el AS Javael servicio puesta en cola mantiene bloqueos lgicos. Cada nodo del clster 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 aplicarn tambin por separado AS ABAP y AS Java. Sin embargo, hay algunas particularidades porque ambos entornos de ejecucin estn integrados entre s en este caso.
Nota: El AS ABAP + Java se conoce como complemento de la instalacin?? 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 ejecucin Java (Java-MS, en Java ES) tambin estn disponibles en el caso de Java central de servicios aqu. Todos los otros casos, generalmente se llaman las instancias de dilogo. Dado que los dos entornos de ejecucin son capaces de responder a las solicitudes a travs de protocolos de la Web, el Gerente de Comunicacin 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 ejecucin 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 ejecucin 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 tambin se mantiene en los esquemas de bases de datos separadas (pero en la instalacin misma base de datos). Es decir, los procesos de trabajo slo se puede acceder a los datos ABAP y los procesos del servidor slo se puede acceder a los datos Java. En el intercambio de datos, tanto en entornos de tiempo de ejecucin a continuacin, se comunican utilizando el SAP Java Connector (JCO). Esta comunicacin es necesaria, por ejemplo, si los datos de facturacin 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 tambin 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 leccin, usted ser capaz de: Entender cmo funciona AS ABAP ListtheASABAP describen los procesos y su propsito Describa cmo las peticiones a AS ABAP se procesan
Los usuarios de inicio de sesin a travs del servidor de mensajes (ABAP) (balanceo de carga) o de inicio de sesin directamente en el despachador de ABAP, los procesos de trabajo ejecutar las entradas de usuario. La tramitacin de una solicitud del usuario en el AS ABAP, como se indica en el grfico, implica procesos diferentes en las tres capas (presentacin, aplicacin 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 presentacin del programa de SAP SAP GUI (interfaz grfica 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 coordinacin con el sistema operativo correspondiente. Las principales tareas de al despachador ABAP incluyen la distribucin de las solicitudes a los procesos de trabajo, la integracin de la capa de presentacin y la organizacin de las operaciones de comunicacin. El despachador primero guarda las solicitudes de procesamiento de colas de peticin 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 asignacin 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 enva a travs de Dispatcher de nuevo a la GUI de SAP. La interfaz grfica 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 Personalizacin de los clientes, tales como las divisas o los cdigos 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 leda desde la base de datos cada vez que sea necesario, pero puede ser llamado muy rpidamente de la memoria intermedia. Cada instancia tiene sus propios buffers.

Figure 36: Process Flow for Requests

Los procesos de trabajo ejecuta la lgica de proceso de los programas de aplicacin. Adems 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 lgica de flujo de pantalla del programa de aplicacin, las llamadas procesamiento mdulos lgicos, y transfiere el contenido del campo de la lgica de procesamiento. La lgica de procesamiento real de los programas de aplicaciones ABAP es ejecutado por el intrprete de ABAP. El procesador de pantalla indica al procesador de ABAP que subprograma necesita ser ejecutada, dependiendo del estado del proceso de la lgica de flujo de pantalla. El proceso de trabajo de dilogo seleccionada por el operador, realiza una votacin en el contexto de usuario en primer lugar. Es decir, los datos que contiene el estado de tramitacin actual de un programa en ejecucin, as como los datos que caracteriza el usuario se da a conocer que el proceso de trabajo. El proceso de trabajo a continuacin, 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 dilogo ha tramitado la etapa de dilogo, 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 Gestin 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 lgica. Los datos, tablas y relaciones entre tablas se definen a nivel de base de datos en el catlogo de base de datos (el diccionario de datos) del RDBMS. En el lenguaje de programacin 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 aplicacin 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 especfico 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 tambin contiene mejoras que no estn incluidos en la norma. En la interpretacin de Open SQL, la interfaz de base de datos de SAP comprueba la sintaxis de estas declaraciones y asegura la utilizacin 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 tcnicos, tales como programas ABAP, pantallas e informacin de ABAP Diccionario, as como una serie de parmetros de administracin de empresas, por lo general permanecen sin cambios en un sistema operativo y por lo tanto ideal para el almacenamiento en bfer.

Figure 37: Database Query Flow

Adems, 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 interpretacin de los comandos. Usted puede hacer esto mediante la inclusin de los comandos en una sentencia EXEC SQL. - END EXEC. Soporte en el programa ABAP. La intrprete 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 ejecucin de las solicitudes de dilogo se caracteriza por lo siguiente: Un paso de dilogo del programa se asigna a un proceso especfico de trabajo de dilogo durante la ejecucin. Los pasos de dilogo individuales para un programa que consta de varias pantallas pueden ser ejecutados por diferentes procesos de dilogo de trabajo durante la ejecucin del programa. Esto se conoce como multiplexado del proceso de trabajo. Un proceso de trabajo de dilogo procesa secuencialmente los pasos de dilogo para los distintos usuarios y programas.

Esto se ilustra por la figura siguiente.

Figure 38: Dialog Work Process Multiplexing

Los programas de la aplicacin SAP diferenciar entre la interaccin del usuario y la lgica de procesamiento. Las acciones de los usuarios son tcnicamente cuenta con pantallas, dynpros tambin llamados (a partir de programas dinmicos), que consisten en una imagen de la pantalla y la lgica de flujo subyacente. El procesador Dynpro del proceso de trabajo ejecuta la lgica de flujo de pantalla del programa de aplicacin, las llamadas procesamiento mdulos lgicos, y transfiere el contenido del campo de la lgica de procesamiento. La lgica 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 enva, y PAI (Proceso despus de la entrada), que se procesa despus de una interaccin con el usuario en la pantalla. La parte de PAI de un paso de dilogo lgicamente pertenece a la imagen de la pantalla anterior, mientras que la parte PBO lgicamente pertenece a la imagen de la pantalla posterior. La lgica de procesamiento real de los programas ABAP es ejecutado por el intrprete de ABAP. El procesador de pantalla indica al procesador de ABAP que subprograma necesita ser ejecutada, dependiendo del estado del proceso de la lgica de flujo de pantalla. Si, durante una etapa de dilogo, los datos necesitan ser intercambiados con la base de datos o los amortiguadores, a continuacin, este intercambio se lleva a cabo a travs 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 especficas. Ellos tienen cuatro caractersticas principales. Las letras iniciales de estas caractersticas forman el acrnimo ACID. Atomic Consistent Isolated Durable

Atomic: significa que una transaccin es completamente satisfactoria o no tiene ningn efecto en
absoluto. Si un sistema orientado a la transaccin 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 trminos de negocio a otro que tambin es precisa y consistente en trminos de negocio. Isolated significa que los cambios realizados dentro de una transaccin slo pueden ser vistos por otras transacciones, incluso las que se ejecutan simultneamente, despus de la confirmacin definitiva (Commit). Los resultados de una operacin son duraderos porque despus de la confirmacin final se almacenan permanentemente en la base de datos.

Database Transactions and ABAP Transactions


Cada proceso de trabajo est conectado a un interlocutor especfico a nivel de base de datos para la duracin de una instancia de SAP tiempo de ejecucin. Los procesos de trabajo no pueden intercambiar los compaeros de comunicacin en tiempo de ejecucin. Esta es la razn por un proceso de trabajo slo puede realizar cambios en la base de datos dentro de transacciones de base de datos. Una base de datos de transaccin 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 transaccin de base de datos se definen por un comando commit (Base de datos de commit) para el sistema de base de datos. Durante una operacin de base de datos (entre dos comandos de confirmacin), 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 despus de una transaccin ha finalizado con un error (Rollback). Las transacciones comerciales se agrupan las unidades de procesamiento para proporcionar una funcin especfica, estas unidades de procesamiento de ejecutar cambios en la base de datos que son consistentes y tienen sentido en trminos de negocio. Ejemplos tpicos son las

actualizaciones de crdito y dbito, que slo tienen sentido en conjunto, o la creacin de un orden y la reserva de los materiales pertinentes. En consecuencia, un AS ABAP transaccin 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 dilogo relacionados lgicamente que sean compatibles en trminos de negocio. Cada paso de dilogo 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 dilogo. Dentro de una operacin 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 transaccin, los cambios deben dar lugar a un estado de base de datos consistente. Los pasos de dilogo individuales pueden ser procesados por los procesos de trabajo diferentes (proceso de trabajo de multiplexacin), y cada proceso de trabajo secuencialmente maneja pasos de dilogo para aplicaciones no relacionadas. Aplicaciones cuyo dilogo pasos son ejecutadas por el mismo proceso un trabajo despus de que el otro no puede funcionar dentro de la transaccin misma base de datos si no estn relacionados entre s. Por lo tanto, un proceso de trabajo debe iniciar una transaccin nueva base de datos para cada etapa de dilogo. La relacin entre las transacciones de bases de datos y transacciones de SAP se ilustra en la grfica de la relacin 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 ms de un usuario en cualquier momento. Para ello, el sistema SAP tiene su propio concepto de gestin de la cerradura. Desde una perspectiva de base de datos, cada paso de dilogo constituye una unidad fsica y lgica: la transaccin de base de datos. La administracin 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 estn formados a

partir de una secuencia de pasos de trabajo lgicamente relacionados que son consistentes en trminos de negocios, generalmente se componen de varios pasos de dilogo. Los sistemas de SAP necesitan tener su propio candado de gestin. Esto se realiza mediante el proceso de trabajo en cola. Esto asegura tambin que la plataforma a la independencia de la gestin 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 slo 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 lgica 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 tambin 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 dilogo de ejecucin de procesos de trabajo con un candado (para ello, el desarrollador de aplicaciones debe programar esta peticin de forma explcita).

Cuando un objeto de bloqueo se activa correctamente en el Diccionario ABAP, el sistema genera un mdulo de funcin enqueue y un mdulo de funcin DEQUEUE con el nombre respectivo: ENQUEUE_<Sperrobjektname> DEQUEUE_<Sperrobjektname> El desarrollador utiliza estos mdulos de funcin en el programa de aplicacin para solicitar

Si una solicitud de dilogo se procesa en el servidor en cola, el proceso de trabajo de dilogo se puede acceder directamente a la tabla de bloqueos. Ahora comprueba si una nueva cerradura puede ser generada, es decir, si hay una colisin con las cerraduras que ya han sido fijados. Si el bloqueo se puede configurar, el proceso de trabajo de dilogo 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 dilogo que se procesa la solicitud del usuario y el proceso de trabajo en cola no se estn ejecutando en la misma instancia, estos dos procesos de trabajo se comunican a travs del servidor de mensajes. En este caso, la solicitud de bloqueo se enva desde el proceso de trabajo de dilogo para el proceso de trabajo en cola a travs 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 dilogo solicitando trabajo a travs 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 aplicacin puede informar al usuario de que la operacin 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. Slo 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 transaccin, un bloqueo de escritura reforzada slo se puede solicitar una vez, incluso por la misma transaccin. Todas las dems 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 aplicacin son puestos en libertad por el mismo programa de aplicacin o por el programa de actualizacin una vez que la base de datos ha sido modificada. Los bloqueos que se han pasado a un proceso de trabajo de actualizacin de esta manera tambin 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 estn establecidas actualmente. Si el bloqueo ya ha sido heredado con el proceso de actualizacin, la bandera de copia de seguridad tambin se ha establecido. Tal bloqueo tambin se incluye en la tabla de bloqueo de nuevo despus de reiniciar el servidor en cola. Hay bsicamente dos maneras de eliminar bloqueos de los usuarios: Poner fin a la sesin del usuario en la informacin general del usuario (transaction SM04 or Tools Administration Monitor System Monitoring User Overview). Eliminar manualmente las entradas de bloqueo en la SM12. El primer mtodo (que finaliza la sesin del usuario) tambin se traduce en el propietario del bloqueo original, dejando a la transaccin y por lo tanto la liberacin de todos los bloqueos, el segundo mtodo (eliminar manualmente usando SM12) simplemente elimina la entrada de bloqueo de la tabla de bloqueos. En teora, esto permite a varios usuarios para cambiar los registros de datos simultneamente. Precaucin: Antes de eliminar bloqueos utilizando la transaccin sm04, los administradores del sistema debe comprobar primero si el usuario que posee el bloqueo se sigue registrando en el sistema. Slo debe eliminar las entradas de bloqueo con la transaccin SM12, si el propietario del bloqueo ya no es iniciado sesin en el sistema, pero todava posee el bloqueo (por ejemplo, si la conexin entre la interfaz grfica 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 sesin 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 tambin 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 ms 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 transaccin de SAP que puede contener varios cambios en la pantalla (por ejemplo, la creacin 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 operacin se termina durante la transaccin o se produce un error, la transaccin no se supone que debe hacer los cambios de base de datos en absoluto. El sistema SAP de actualizacin, que se describe a continuacin, se encarga de esto.

El sistema de actualizacin tambin ofrece mayor seguridad, rendimiento y restaurabilidad en la ejecucin de los cambios de base de datos.

Figure 41: The principle of asynchronous updates

El sistema de actualizacin es una tecnologa 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 asincrnica en los procesos de actualizacin especiales de trabajo. Tambin evita los problemas de espalda rollo-causadas por la diferencia en la concepcin de la unidad lgica de trabajo (LUW) en una transaccin de SAP y en la base de datos. Si durante un proceso de trabajo de dilogo, los datos almacenados temporalmente para su procesamiento se pasa a un proceso de trabajo de actualizacin para su posterior procesamiento, el proceso de trabajo de dilogo no espera a que la solicitud de actualizacin a realizar: la actualizacin de forma asncrona (no simultnea). El proceso de actualizacin asncrona se ilustra en el grfico El principio de actualizaciones asincrnicas. La parte de dilogo se completa con el comando COMMIT WORK ABAP, la parte de actualizacin de la transaccin se inicia: el servidor de actualizaciones transfiere la solicitud de actualizacin a un proceso de trabajo de actualizacin. Aqu, cada paso de dilogo corresponde a una transaccin 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 actualizacin de la transaccin SAP se ejecuta en una transaccin de base de datos. Es slo entonces que los datos se copian en las tablas de aplicacin.

Figure 42: The asynchronous update process

Si los usuarios desean cambiar de un registro de datos en una transaccin de SAP, que ellos llaman la transaccin correspondiente en el cuadro de dilogo, hacer que las entradas correspondientes en las pantallas y luego iniciar el proceso de actualizacin 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 transaccin SAP. 3. En el proceso de dilogo de trabajo activo, el programa llama a un mdulo de funcin utilizando CALL FUNCTION... IN UPDATE TASK y escribe la solicitud de cambio de tablas de actualizacin de bases de datos. stos tambin se llaman VB * Las tablas, debido a que sus nombres empiezan con VB. Actan como memoria temporal y almacenar los datos que han de cambiarse hasta que pueda ser recogido y se escriben en las tablas de aplicacin en la base de datos (en una operacin nica base de datos). 4. Al final de la parte de dilogo de la transaccin (por ejemplo, cuando el usuario guarda los datos posiblemente, despus de completar otras medidas de dilogo), el programa inicia el cierre de la transaccin con la sentencia COMMIT WORK. El proceso de trabajo que se encarga de la etapa de dilogo activo completa la cabecera de actualizacin y desencadena un proceso de trabajo de actualizacin. 5. Sobre la base de la informacin (clave de la orden de actualizacin, bloqueo del teclado) transferidos desde el proceso de trabajo de dilogo, el proceso de trabajo de actualizacin lee los registros que pertenecen a esta transaccin SAP de las tablas VB. 6. El proceso de trabajo de actualizacin transfiere los cambios marcados y recogidos en las tablas VB* a la base de datos como una solicitud de cambio y evala la respuesta de la base de datos. Si los cambios fueron escritos con xito a las tablas de destino, el

proceso de trabajo de actualizacin de base de datos activa un commit despus de la ltima modificacin 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 cmo utilizar las actualizaciones asncronas en la programacin de la transaccin. Adems de la actualizacin asncrona, hay algunas tcnicas de actualizacin de otros (por ejemplo, sncrono o local). Para aumentar el rendimiento an ms, los desarrolladores de aplicaciones pueden configurar diferentes tipos de actualizaciones: tiempo crtico, primarias actualizaciones V1. Ellos son relevantes para los objetos que tienen una funcin de control en el sistema SAP, tales como un cambio en el stock de material o una creacin de la orden. tiempo no crtico, actualizaciones secundarias V2 que dependen de las actualizaciones de V1. Estos son, por ejemplo, las actualizaciones puramente estadsticas como el clculo de los resultados. no tiempo crtico las actualizaciones que se recogidos y tratados en un momento posterior en el tiempo (plazo colectiva). Los mdulos de V1 para una transaccin de SAP se procesan de forma secuencial en un proceso de actualizacin sola obra. Si su sistema SAP tiene un proceso de trabajo para las actualizaciones V2 (UP2 tipo), a continuacin, los mdulos V2 slo se actualizar all. De trabajo V1 libera los bloqueos pertinentes una vez ms. Esto significa que elNormales actualizar los procesos de trabajo volvern a estar disponibles ms rpidamente para el tiempo las actualizaciones crticas de V1, y que las entradas de bloqueo correspondientes se eliminan antes. Si usted no ha configurado todos los procesos de actualizacin V2 de trabajo, entonces el proceso de trabajo V1 se encarga de todas las actualizaciones. En el largo colectivo, los mdulos no se actualizan automticamente, pero slo cuando un informe especial (informe RSM13005) desencadena la actualizacin. Todas las llamadas de los mdulos de funcin se recogen a continuacin, agregar y actualizar a la vez. Al hacerlo, se manejan como los mdulos de actualizacin de V2. Si ocurre un error durante una actualizacin, entonces el procesamiento del componente de actualizacin activa termina. Los usuarios pueden recibir automticamente una notificacin por correo expreso, cuando finaliza la actualizacin. Si un proceso de trabajo de dilogo termina, mientras que la escritura de datos en las tablas *VB, las tablas contienen datos que no se actualizarn. Estas entradas pueden ser automticamente eliminadas la prxima vez que inicie el sistema o pueden ser eliminados manualmente. Las tablas de aplicacin permanecen sin cambios. Una actualizacin asncrona 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 condicin de excepcin Clave duplicada en la codificacin, 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 ms de una vez.

Cuando termina una actualizacin, el sistema enva un correo rpido al usuario que haya activado la actualizacin. Cualquier medida adicionales deben ser llevadas a cabo por el administrador del sistema. Transaccin SM13 (solicitudes de actualizacin) proporciona a los administradores de sistemas con herramientas de anlisis para manejar las actualizaciones terminadas. Una vez que el error que caus la extincin se ha corregido (por ejemplo, daos en el hardware reparado), el usuario final debe reiniciar el proceso.

Print
Los sistemas de SAP ofrecen una amplia variedad de opciones para la representacin de las empresas y otros datos. Estos datos, creados y formateados en una etapa de dilogo, se pueden enviar a las impresoras y otras interfaces de salida (fax, correo electrnico, 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 eleccin del icono de impresin (Ctrl + P), a continuacin, utilizando la ayuda F4. Una impresora estndar 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 informacin que necesita para ser capaz de crear una orden SPOOL. La solicitud spool contiene informacin 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 dilogo, 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 grfico de procesamiento de cola de impresin 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 conexin de red). Nota: En un sistema SAP, la conexin entre un proceso de trabajo spool y el proceso del sistema operativo spool es conocido como el mtodo de acceso. Hay ms mtodos de acceso que se muestran ms arriba. Estos son los dos ms comnmente utilizados los mtodos de acceso para la conexin de impresoras con los sistemas SAP. En este contexto, local o remoto no se refieren a la ubicacin fsica de la produccin, sino al lugar donde el proceso de trabajo es spool Conectado al sistema de proceso de operacin de carrete. Para el procesamiento de impresin, el mejor rendimiento se consigue mediante el envo de los datos a imprimir en el sistema operativo tan pronto como sea posible. Para ello, utilice el mtodo 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 impresin de los sistemas de SAP es que cada impresora seleccionable permite la impresin a nivel de sistema operativo. Usted puede mostrar su propio spool, y pide la salida a travs de System Own Spool Requests (transaction SP02). Via System User Profile Own Datos (cdigo de transaccin SU3) se puede especificar la configuracin personal para la impresin en la pgina de ficha Valores predeterminados en la seccin Spool Control.

Background processing
Procesamiento de SAP de background es un mtodo para automatizar tareas rutinarias y para optimizar el uso de su organizacin de SAP los recursos informticos. 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 duracin 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 tensin en los recursos de dilogo y los informes que se ejecutan en el background no estn sujetos a las restricciones de tiempo de ejecucin de la elaboracin de dilogo (la terminacin del programa despus de un tiempo de ejecucin de diez minutos). La segregacin de procesamiento en segundo plano a los procesos especiales de trabajo le da una dimensin 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 da 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 tambin por los servidores porque los trabajos de background slo 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 transaccin de la aplicacin. El trabajo entonces Espera para el tiempo de ejecucin previsto en la tabla de planificacin de tareas. Si el tiempo ha llegado y los procesos de trabajo libres de antecedentes estn 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 transaccin de aplicacin o, en el caso de los programas de generacin de la lista, mira a la solicitud de spool perteneciente a su trabajo (vase la seccin de impresin). Para mostrar sus propios puestos de trabajo, elija Sistema Jobs propios (cdigo de transaccin SMX). La administracin del sistema y la preparacin del trabajo tienen acceso a una herramienta para la programacin de los diferentes tipos de background toma con la operacin SM36 (Tools CCMS Background Processing Define Jobs). El monitoreo de todo el sistema de puestos de trabajo se lleva a cabo con la transaccin SM37 (Tools CCMS Background Processing Jobs - Overview and Administration).

Para la programacin 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 comunicacin 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 peridicamente.

Figure 45: Gateway Communication

En la comunicacin 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 dilogo tiene que establecer una conexin RFC a un sistema remoto en el contexto de una peticin, por ejemplo, para recuperar los datos del cliente, se utiliza la puerta de entrada, que a continuacin se hace cargo de la comunicacin con el sistema remoto. El gateway enva la solicitud del gatwey del sistema remoto. El gateway remoto transfiere la solicitud al dispatcher. Esto a su vez enva la solicitud a uno de sus procesos de trabajo, que la comunica directamente con su gatwey. Conexin 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 direccin URL para decidir a donde se enva 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 ejecucin Java, se enva al distribuidor de Java (2b), que a su vez lo reenva a un proceso de servidor Java (3b). Si la solicitud es el entorno de ejecucin ABAP, el ICM se remite al despachador ABAP (2a), el cual se maneja como una tpica peticin de SAP GUI (ver seccin 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).