Manual c. basico sap

CURSO BÁSICO DE SAP R/3

Noviembre, 2005

Curso Básico de SAP / R3

Noviembre, 2005

CURSO BÁSICO DE SAP/R3

1. SAP R/3.
 ¿Qué es SAP?
 ¿Para que sirve SAP?
 Estructura Funcional del Sistema.
 Conceptos del Business Framework

2. Arquitectura de un sistema SAP
 BD – Servidor de aplicación – Front end
 Cliente/Servidor.

3. Toma de contacto con el entorno SAP.
 Interface de usuario R/3
 Navegación
 Técnicas de parametrización: visión general

4. Plataforma Tecnológica
 Hardware, S.O., Bases de Datos
 Comunicaciones

5. Administración y servicios Remotos
 Principios de seguridad en R/3
 Funciones del Administrador
 Administración de usuarios
 Computing Center Management System (CCMS)
 Online Service System (OSS)
 Servicios de soporte de SAP

Página 2 de 77


Noviembre, 2005

6. Estructura de un S.I. SAP
 Niveles del S.I. (Básico, ampliaciones, modificaciones)
 Mandantes
 Servicios (Dispacher, job´s, spooling, instancias)

7. Entorno de Desarrollo de SAP R/3
 Introducción
 Workbench ABAP y lenguaje de desarrollo ABAP/4
 Herramientas (diccionario, reports, consultas, bach-inputs, job´s, ...)
 Interfaces de comunicación (CPI-C, RFC, EDI, ALE, OLE)
 Integración de SAP con Internet
 My SAP
 WorkPlace.
 Business Information Warehouse.
 Business to Business Procurement – Marketplaces
 Online Store / CRM / Internet Sales.

Página 3 de 77


Noviembre, 2005

Objetivos del curso

El objetivo del presente curso pretende un acercamiento a la metodología de trabajo de SAP,
así como una toma de contacto con toda la terminología utilizada por SAP. La gran mayoría
de los términos utilizados en la notación de SAP, son fácilmente distinguibles, así como muy
intuitivos. Con el propósito de facilitar la inmersión en esta nueva tecnología, se impartirá
este curso al personal de la entidad familiarizado con entornos de desarrollo o administración,
siendo estos las personas que tendrán que familiriarizarse con toda esta terminología básica de
administración y desarrollo.

En este curso se explicarán desde conceptos de la arquitectura SAP, pasando por las técnicas
básicas de navegación a través de las pantallas de SAP, hasta una explacación detallada de
todos los servicios de SAP, en términos de administración y desarrollo.

Este curso acompaña todas las explicaciones con fotografías, para facilitar la idea intuitiva de
los conceptos que se esten desarrollando.

Página 4 de 77


Noviembre, 2005

1. SAP R/3

Enterprise Resource Planning o ERP es un término utilizado en la industria para denominar a
los paquetes de software de aplicaciones multimodulares diseñados para soportar múltiples
funciones de negocio. Ejemplos de ERPs son JD Edwards, Baan, Meta-4, etc.
Los módulos de la ERP son capaces de interactuar con el plicaci propio de la plicación t,
y pueden ser alterados por el cliente para que se adapte a sus procesos específicos de negocio.
SAP (Systems, Applications, and Products in Data Processing) es la ERP lider del plicac.
SAP fue el primero en integrar todas las funciones corporativas plicación te en una única
plicación.

Página 5 de 77


Noviembre, 2005

Página 6 de 77


Noviembre, 2005

Página 7 de 77


Noviembre, 2005

Página 8 de 77


Noviembre, 2005

Página 9 de 77


Noviembre, 2005

Página 10 de 77


Noviembre, 2005

Página 11 de 77


Noviembre, 2005

Página 12 de 77


Noviembre, 2005

Este dibujo nos muestra la división de los diversos módulos de SAP. Todos ellos se agrupan
en categorías funcionales de la siguiente manera:

Logística: SD, MM, PP, QM, PM
Contabilidad: FI, CO, TR, PS
Recursos Humanos: HR
Soluciones Sectoriales/Aplicaciones Intermodulares: IS, WF

Página 13 de 77


Noviembre, 2005

R/3 Integration Diagram
 Extensive business Accounting
functions
Logistics SD FI
Sales & Financial
Distribution Accounting
MM
CO
Materials
Controlling
Mgmt
PP TR
Production Treasury
Planning
R/3
QM
Quality
Mgmt PM
Basis PS
Project
System
Plant WF
Main- Workflow
tenance HR IS
Human Industry
Resources.
. Solutions

Human Resources Industry /
Cross-Application
R

 SAP AG

 La principal característica de los componentes del sistema R/3, es la combinación de la
más moderna tecnología con las funciones de negocio. El alto nivel de integración de esta
aplicación permite que todas las funciones puedan ser accedidas directamente a través del
sistema, así como toda la compañía. Cuando se implante el sistema R/3, los datos son
integrados en una única base de datos.
 Realizando los procesos de negocio con el sistema R/3, no nos restringimos a un modulo
de aplicación individual. Todos los datos y funciones están interconectados unos con otros,
asegurando así la coherencia de los mismos, así como un flujo de datos mucho más
efectivo, posibilitando la ejecución de todo tipo de procesos de negocio.

Página 14 de 77


Noviembre, 2005

 El Business Framework es la nueva arquitectura de los sistemas R/3, desde el punto de
vista del negocio.
Se trabaja con componentes de negocio, los cuales son módulos de software configurables,
aportando así dinamismo a toda la infraestructura de la empresa. Además, este nuevo
software puede ser acoplado rápidamente a los nuevos requerimientos del negocio, o
mejorado simplemente, sin ningún tipo de interrupción en el proceso diario de trabajo.
Utilizando la Business Framework technology Therefore, SAP provee a sus clientes con
una nueva plataforma para configurar y conectar procesos de negocio y flujos de
información a través de todos los marcos de trabajo.
 Ejemplos de componentes de negocio: FI (Financial Accounting), LO (Logistics), HR
(Human Resources) o componentes industriales para la formación de aplicaciones
específicas o aplicaciones de Internet como el Business-to-Business, Consumer-to-
Business y aplicaciones de Intranet .
 Las ventajas de la Business Framework Architecture (BFA) incluyen la capacidad de
facilitar los cambios y de configurar dinámicamente procesos de negocio, así como la fácil
integración de los componentes de Internet e Intranet en sus procesos de negocio,
conexiones simples entre R/3 y otro software, desarrollos propios del cliente, así como una
implementación de la más avanzada tecnología, todo ello sin interrumpir las operaciones
del negocio.

Página 15 de 77


Noviembre, 2005

 El gráfico de Business Framework graphic nos muestra al sistema R/3 como una familia de
distintos componentes integrados.
 Componentes:
Business Components (Human Resources, por ejemplo)
Business Objects (Facturas, empleados, por ejemplo)
BAPI-Interfaces (crear una factura, cambiar la dirección de un empleado, ...)
 Los componentes del negocio interactuan en el Business Framework sobre Business
Application Programming Interfaces (BAPIs). BAPIs también proporcionan un interfaz
estable y estandar, para integrar aplicaciones y componentes externos en el Business
Framework. Estos interfaces están definidos para facilitar la integración del marco de
trabajo de SAP con clientes y partners .
 Para distribuir la información de negocio en el Business Framework, existen tecnologías
como Application Link Enabling (ALE). ALE garantiza la integración entre los
componentes de negocio.

Página 16 de 77


Noviembre, 2005

2. Arquitectura de un sistema SAP

 El sistema R/3 System posee una arquitectura modular de software que nos permite aplicar
el principio de cliente/servidor. Esta arquitectura constituye la base de las diferentes
opciones que tiene el cliente para planificar y realizar su instalación de SAP R/3. Tanto una
configuración central como una distribuida con numerosos servidores dedicados, son
soportadas por SAP.
 Esta arquitectura nos permite separar los niveles de aplicación de los niveles de
presentación y de base de datos. Esto es un requisito para poder aplicar balances de carga,
así como de utilizar el rendimiento potencial de las actuales estructuras, en próximas
generaciones de hardware.
 Esta arquitectura nos proporciona escalabilidad, osea, ajustar nuestro rendimiento a las
demandas actuales, por ejemplo, si ha aumentado el número de usuarios o porque se han
añadido módulos adicionales.
 Características y utilización de la escalabilidad de los sistemas R/3
 Instalación de servidores adicionales para la eliminación de cuellos de botella.
 Servidores paralelos para homogeneizar la carga y ejecución local de los programas.
 Buffers de datos y programas cerca de los procesadores.
 Logon y balance de carga (distribución de usuarios a servidores dedicados, distribución
de carga de los procesos de background)

Página 17 de 77


Noviembre, 2005

 En la terminología de SAP, un componente de software proporciona un servicio In SAP
terminology, a software component provides a service (software-oriented view). Este tipo
de componentes pueden consistir de un proceso o de un grupo de procesos, y en función de
estos, así será llamado el servidor ( Por ejemplo, si un servidor tiene servicios de spool,
será un servidor de spool).

Página 18 de 77


Noviembre, 2005

Los niveles principales son el nivel de presentación, el nivel de aplicación y el nivel de base
de datos.
 En un sistema R/3 central, todas las tareas de procesamiento son realizadas por un solo
host, respondiendo así con el procesamiento clásico de los mainframe processing, con
terminales X .
 Una configuración de sistemas R/3 de dos niveles son implementadas utilizando
servidores de presentación especiales, cuya única responsabilidad es la de formatear
el interfaz gráfico.
 En una configuración de tres niveles, utilizas como mínimo un host, para cada uno de los
tres niveles. Utilizando los datos de la base de datos, diferentes servidores de aplicación,
pueden operar al mismo tiempo. Además, con objeto de optimizar el rendimiento, puedes
aplicar desde el balance de carga, alta disponibilidad de spool, así como servidores
dedicados para cierto tipo de aplicaciones.

Página 19 de 77


Noviembre, 2005

 Los sistemas R/3 referencian a todos los componentes de software que están asignados a la
misma base de datos. The R/3 System refers to all software components that are assigned
to the same database.
 Si se utilizan las opciones de distribución de los sistemas R/3, de acuerdo con los
principios de cliente/servidor, los componentes de R/3 se desplegaran en una jerarquía de
tres niveles.
 El servidor de base de datos es instalado en un host dedicado.
 Varios servidores de aplicación se podrán conectar a la base de datos.
 Varios servidores de presentación podrán conectarse con cada servidor de aplicación. A
estos servidores también se les llamara frontends (workstation, PC). Estos ordenadores
procesara, todas las tareas de presentación. Los usuarios trabajaran interactivamente con
R/3, utilizando el interfaz proporcionado por los servidores de presentación.

Página 20 de 77


Noviembre, 2005

3. Toma de contacto con un entorno SAP

Logging On

Client
Client

User
User

Password
Password

Language
Language

R

 SAP AG

 El sistema R/3 es un sistema basado en mandantes (clientes). Con el concepto de
mandante, se pueden controlar diferentes empresas sobre el mismo sistema R/3. Cada
sesión de usuario solo accede a los datos del mandante que selecciono al entrar.
 El sistema R/3 es multi lenguaje. El idioma por defecto es parametrizable.

Página 21 de 77


Noviembre, 2005

Pantalla

Display Customer Line Items: Initial Screen
Line items Edit Goto Settings Environment System Help
Título Opciones

Customer
Comandos Barra de
Company code
Herramientas
Line item selection
Open items
Cleared items
Checkboxes Parked items
With vendor line items

Selection criteria... With work list Botón

Settings List begins with
Line layout Standard Line items
Totals variant Totals Botón radio
13:10
Barra de estado
R

 Barra de título: La barra de título muestra donde la tarea actual de trabajo.
 Campo de comandos: Desde aquí se puede ir a una tarea directamente introduciendo el
código de transacción.
 Opciones: Desde aquí se puede cambiar algunos aspectos del interface R/3.
 Barra de herramientas: En esta barra se encuentran los iconos de navegación, salvado,
ayuda, etc.
 Checkboxes: Los checkboxes permites seleccionar varios items al mismo tiempo.
 Radio buttons: Los radio buttons permiten seleccionar exactamente un item.
 Barra de estado: Muestra información sobre el estado actual del sistema (Nombre del
sistema, mandante, sesión, usuario, etc.

Página 22 de 77


Noviembre, 2005

Procedimiento de Customizing

 El Customizing Organizer y el Sistema de Gestión de Transportes están diseñados para
trabajar juntos. Durante el proceso normal de parametrización:
 El jefe de proyecto define la orden de transporte y las tareas subsidiarias para todos los
usuarios implicados.
 Estos usuarios realizan los cambios en el customizing, que son grabados en la orden de
transporte.
 Después de completar el customizing, los usuarios deben liberar sus tareas.
 La orden de transporte puede ser liberada desde el sistema origen para exportarla al
sistema operativo.
 El transporte al sistema destino tiene lugar a nivel de sistema operativo.

Página 23 de 77


Noviembre, 2005

4. Plataforma tecnológica

R/3 Basis Middleware
SD FI
FI
SDSD FI
Financial
Sales & Financial
Sales &
CO
COCO
MM
MM
MM Controlling
Materials Controlling
PP Materials
PPMgmt AM
AM
Mgmt AssetAM
R/3
Production Mgmt

R/3
Production
Planning Asset Mgmt
Planning

QM
QM
QM
Client / /Server
Client Server PSPS
Project
Quality Project
Quality
Mgmt
MgmtPM ABAP/4
ABAP/4 WF
System
System
PM
Plant Main- WF
WF
Plant Main- Workflow
tenance Workflow
HR
tenance
HR IS
IS
Human Industry
Human
Resources Industry
Solutions
Resources Solutions

R/3 application

ABAP
Workbench

R/3 Basis (Middleware)

System Software R

 SAP AG

 Utilizando el sistema básico de R/3, las aplicaciones pueden correr sobre diferentes
plataformas con un alto rendimiento, y pueden ser adaptadas a los requerimientos
individuales de cada usuario.
 R/3 Basis software (también llamado middleware):
 Proporciona el entorno de ejecución para las aplicaciones de R/3
 Se encarga del óptimo acoplamiento e inclusión de las aplicaciones en el entorno del
sistema.
 Define la arquitectura de un marco de trabajo estable, para facilitar las mejoras del
sistema.
 Contiene las herramientas para administrar todo el sistema.
 Proporciona recursos y componentes de sistemas para ser distribuidos
 Proporciona interfaces para descentralizar partes del sistema en productos externos
 Características de la tecnología del módulo básico:
 La arquitectura del sistema básico de R/3 es compatible con la estructura de una
configuración cliente / servidor
 Bases de Datos relacionales
 Interfaz de usuario gráfico (GUI)

Página 24 de 77


Noviembre, 2005

R/3 Basis System Overview
Applications
Programming interfaces

Communication interface
Benutzerschnittstelle

Benutzerschnittstelle
Screen interpreter ABAP
User interface

interpreter
ABAP
Dictionary

Flow control

System interfaces

System software and platforms R

 SAP AG

 El interfaz de usuario proporciona las opciones de presentación.
 Los interfaces de comunicación definen los canales para el intercambio electrónico de
información, para transferencia de datos, o para la comunicación programa a programa de
acuerdo con el protocolo CPI-C y para el intercambio estándar de datos utilizando ËDI.
 Todos los programas de aplicación de los sistemas R/3, están hechos en ABAP IV, que es
propio lenguaje de programación de SAP. Los componentes de control para la secuencia de
pantallas se denominan DYNPROS (= programas dinámicos). La interacción entre las
pantallas y los interpretes ABAP, forman la base tecnológica de las aplicaciones de los
sistemas R/3. Ambos intérpretes utilizan una vista global de todos de todos los datos del
sistema R/3, que se almacenan en el ABAP Dictionary.

Página 25 de 77


Noviembre, 2005

Plataformas para los sistemas R/3

Hardware UNIX Systems Bull/Zenith Digital NCR
Bull IBM Compaq HP (Intel) Sequent IBM IBM
Digital SNI Data General IBM (Intel) SNI AS/400 S/390
HP SUN ...

Sistemas
AIX Reliant
operativos
Digital UNIX UNIX (SINIX) Windows NT OS/400 OS/390
HP-UX SOLARIS

Bases de DB2 Common Server DB2 Common Server
datos INFORMIX OnLine
INFORMIX-OnLine DB2 for DB2 for
INFORMIX OnLine
INFORMIX-OnLine AS/400 OS/390
ORACLE ORACLE
MS SQL Server

Windows 3.1, Windows 95, Windows NT,
SAPGUI OSF/Motif *, OS/2 Presentation Manager (PM),
Macintosh *, Java

Lenguajes
ABAP, C, C++, HTML, Java
R

*

 El sistema R/3 se basa en una arquitectura abierta, eso significa que es extremadamente
portable.
 El R/3 es totalmente compatible con todas las plataformas UNIX importantes, Windows
NT, AS/400 y S/390.
 Soporta diferentes bases de datos como Informix, Oracle, ADABAS, DB6, DB4, DB2,
SQL Server, etc.
 El interfaz gráfico de usuario (SAPGUI), también es compatible con sistemas operativos
como Windows, OS/2, UNIX, y Mac.

Página 26 de 77


Noviembre, 2005

El landscape recomendado por SAP contempla estos tres sistemas.

Página 27 de 77


Noviembre, 2005

Interfaces

 General communication
 CPI-C communication
 RFC
 Business Objects and BAPIs
 OLE
 Internet architecture
 EDI
 ALE
 Data Transfer into the R/3 System

R

 SAP AG

Página 28 de 77


Noviembre, 2005

Objectives

 Define the R/3 System as an open system.

 Recognize the principle communication mechanisms
in an R/3 System.
 Discuss the options the R/3 System provides when
you transfer legacy data.

R

 SAP AG

Página 29 de 77


Noviembre, 2005

Communication: R/3 as an Open System
Application
layer

OLE Automation

Presentation RFC
layer /
session layer
CPI-C (SAP implementation)

Transport LU6.2
layer (R/2) TCP/IP
(R/3)
Network
layer
Ethernet

Ethernet
Connection

Token ring
Token ring

layer ... X.25 ...
R

Physical
layer
 SAP AG

 El sistema R/3 es un sistema abierto. Soporta una gran variedad de protocolos de
comunicación en redes. La información puede ser intercambiada entre un sistema R/3 y
otro R/3, R2 u otro sistema que no sea SAP a través de la red.
 SAP soporta el protocolo TCP/IP (Transmission Control Protocol/Internet Protocol) y el
SNA LU6.2 (System Network Architecture; Logical Unit 6.2) . La comunicación entre
sistemas R/3 se realiza con el protocolo standar TCP/IP. LU6.2 fue desarrollado por IBM
y se utiliza para comunicarse con sistemas R/2 sobre mainframes.
 La programación de aplicaciones R/3 soporta CPI-C (Common Programming Interface
Communication), RFC (Remote Function Call) y Automatización OLE (Object Linking
and Embedding) como interfaces de comunicación.

Página 30 de 77


Noviembre, 2005

El protocolo CPI-C protocol conecta protocolos tipo LU6.2 y TCP/IP. Además se puede
utilizar CPI-C para conectar mainframes (Sistemas R/2) y sistemas cliente servidor (Sistemas
R/3).
 El SAP gateway (Manejador de CPI-C) es un grupo de procesos que permiten la
comunicación entre sistemas R/2, sistemas R/3 y aplicaciones externas basadas en el
protocolo CPI-C .
 Mientras mensajes cortos son intercambiados entre los servidores de aplicación a través del
message server en un sistema R/3, gran cantidad de datos (datos de aplicación) fluyen a
través del SAP gateway. Esto significa que el medio de comunicación, puede ser parte del
mismo sistema, o de un sistema R/3 diferente o de un sistema R/2, o formar parte de un
programa externo.
 En los sistema R/3 , los procesos del SAP gateway que se comunican clientes basados en el
protocolo TCP/IP . LU6.2 (de IBM) se utiliza para mainframes.

Página 31 de 77


Noviembre, 2005

 Los sistemas R/3 soportan el CPI-C “starter set” como un método elemental de
comunicación programa-a-programa. Es utilizado para la comunicación entre sistemas R/2
o (mainframes) aplicaciones, para las cuales no se puede o no se quiere utilizar otros
protocolos más fáciles de utilizar.
 ABAP contienen seis comandos de comunicación:
 COMMUNICATION INIT – especifica parámetros de comunicación
 COMMUNICATION ALLOCATE - estructura la comunicación
 COMMUNICATION ACCEPT - acepta la comunicación
 COMMUNICATION SEND – envía datos
 COMMUNICATION RECEIVE – recibe datos
 COMMUNICATION DEALLOCATE – fin de la comunicación
 Una vez que la comunicación se ha establecido, se llama a un programa para enviar datos.
En este punto, el otro programa debe estar preparado para recibir datos. El emisor y el
receptor pueden cambiar. Al final de la transferencia de datos, la conexión se corta.
También se puede configurar el buffer de envío, para así evaluar los códigos de retorno.
 Para la comunicación CPI-C con programas externos, además de las CPIC Advanced
Function Calls (para convertir ASCII a EBCDIC, por ejemplo) SAP también proporciona
funciones en la forma de librerías de C (para establecer una cadena de conexión, por
ejemplo).
 Los parámetros relacionados con la conexión, no son componentes del programa de
comunicación. Se puede mantener la tabla TXCOM utilizando la Transacción SM54.

Página 32 de 77


Noviembre, 2005

Remote Function Call
R/3 System
ABAP
ABAP
ABAP
Programm RFC
Programm
program
interface

CPI-C

CPI-C CPI-C
ABAP
ABAP
Programm
Programm ABAP
Programm
Programm
Program Programm
program
RFC RFC
interface interface
R

External system R/2 System
 SAP AG

 Remote Function Call (RFC) es un interfaz de comunicación basado en CPI-C, pero con
muchas más funciones y más fácil de manejar por los desarrolladores. Se pueden utilizar
sistemas R/3 y R/2 así como aplicaciones externas de comunicación RFC.
 RFC es el protocolo para llamar a subrutinas especiales a través de la red. Estas subrutinas
están etiquetadas como módulos de función. Estos módulos de función son comparables a
las funciones de C o a los Procedures de PASCAL. Estos módulos poseen un interfaz
definido, por el cual datos, tablas y códigos de retorno pueden ser intercambiados. Estos
módulos de función son manejados en el sistema R/3 en sus propia librería de funciones,
llamada Function Builder.
 El Function Builder (Transacción SE37) provee a los programadores de aplicaciones con
un útil entorno de programación, documentando testeando aplicaciones, las cuales pueden
ser llamadas tanto localmente como remotamente. El sistema R/3 genera el código
adicional requerido para las llamadas remotas (RFC Stub) automáticamente.
 Los requerimientos técnicos para RFC son los mismos que los de CPI-C. Se mantienen los
parámetros de las conexiones RFC, utilizando la transacción SM59. Los sistemas R/3
también proporcionan el RFC-SDK (Software Development Kit) que utilizan gran
cantidad de librerías de C para permitir a los programas externos conectarse con el sistema
R/3.

Página 33 de 77


Noviembre, 2005

RFC from R/3 System to R/3 System

88MHz

Calling system Called system
ABAP coding

RFC
...
CALL FUNCTION XY FUNCTION XY.
DESTINATION... .
EXPORTING... .
IMPORTING... .
... ENDFUNCTION.

R

 SAP AG

 Los módulos de función de llamadas remotas se diferencian de los módulos de función de
llamadas locales en un parámetro (Destination) que específica el host de destino donde el
programa va a ejecutarse.
 Hay tres tipos de llamadas RFC :
 Llamada RFC Síncrona: la llamada del programa para hasta que el módulo de función
ha sido procesado en el sistema destino, y algún resultado ha sido devuelto al emisor.
Sólo así permite al programa emisor continuar ejecutándose.
 Llamada RFC Asíncrona: El programa emisor corre paralelo e independiente del
procesamiento de la llamada en el sistema destino. Los programadores son
responsables del procesamiento del manejo del resultado de la llamada. Además , el
sistema destino ha de estar disponible en el momento de la llamada RFC.
 Llamada RFC Transaccional: Varios módulos de función pueden agruparse en una
transacción. Estos son procesados solamente en el sistema destino con una LUW
(Logical Unit Work), y siguiendo la secuencia en que han sido llamados. En el caso de
un error, el sistema emisor recibe una confirmación de que puedes acceder utilizando la
Transacción SM58. . En el caso de una llamada RFC Transaccional, el sistema destino
no tiene porque estar disponible en el mismo momento que la llamada RFC. Además,
se puede configurar la frecuencia y el intervalo de consultas individuales.

Página 34 de 77


Noviembre, 2005

 Los Business objects forman la base para la comunicación al más alto y más amigable de
los niveles de comunicación (network layers) . Estos permiten a los sistemas R/3 desde
conectarse a Internet a conectarse con programas de escritorio (Excel). SAP utiliza estos
business objects con el objetivo de integrar objetos al nivel de negocio más que a un nivel
puramente técnico.
 Business objects:
• Forman la base de al comunicación amigable entre sistemas cliente / servidor .
• Están orientados al negocio: hay objetos como “Cliente”, “Factura”, “Oferta”, por
ejemplo.
• Proporcionan funciones (métodos) de negocio . Para un objeto “Cliente”, por ejemplo hay
“Crear Cliente” y “Ver Cliente”. Estos nombre permiten la claridad y así evitar errores de
programación.
• Son manejados centralmente desde el sistema R/3 en el Business Object Repository
(BOR).
 BAPIs (Business Application Programming Interfaces) interfaces funcionales. Utilizan los
métodos de negocio de los business objects. Las BAPIs pueden ser utilizadas desde los
sistemas R/3 o externamente.

Página 35 de 77


Noviembre, 2005

R/3 System as an OLE Client

188
188

R/3
SAPGUI
SAPGUI
ABAP
ABAP
program
program
PC
PC OLE
OLE RFC
program
program server
server

R

 SAP AG

 OLE (Object Linking and Embedding) es una camino orientado a objetos para la
comunicación entre programas. Se puede conectar aplicaciones de escritorio al sistema
R/3, para programas que utilizan la Automatización OLE2 (Word, Excel). De esta manera
los usuarios pueden utilizar el sistema R/3 sin tener que sacrificar su entorno habitual de
escritorio.
 Si el sistema R/3 actúa como un cliente OLE, entonces el usuario llama a las aplicaciones
de escritorio desde las aplicaciones ABAP. Los comandos OLE son transferidos desde el
código vía RFC por el SAPGUI al PC. El SAPGUI mapea las llamadas RFC a los
comandos OLE de la aplicación del PC.
 Las funciones OLE de los programas de escritorio están especificados en el sistema R/3 en
el tipo de información. Esta información contiene una descripción de los métodos, atributos
y parámetros. El tipo de información es independiente del idioma.
 ABAP contiene cinco comandos especiales OLE CREATE OBJECT, CALL METHOD,
GET/SET PROPERTY y FREE OBJECT con los que se pueden acceder a las funciones de
escritorio.

Página 36 de 77


Noviembre, 2005

R/3 System as an OLE Server

188

R/3
RFC Function
SAP
modules
PC automation RFC
program API
server
Business
Data objects
BAPIs

R

 SAP AG

 Cuando el sistema R/3 se utiliza como un servidor OLE, sus funciones pueden ser llamadas
desde una aplicación de escritorio. Este envía comandos OLE al SAP Automation server.
El servidor convierte estos comandos en llamadas RFC y las envía al sistema R/3. Este
lanza módulos de función o BAPIs de los business objects en el sistema R/3 . Una vez
que estas han sido procesadas, sus datos se envían vía SAP Automation Server de vuelta a
la aplicación de escritorio.
 Los usuarios pueden utilizar los módulos de función del sistema R/3. La programación es
orientada a objetos, por ejemplo Visual Basic o Visual C++.
 Los business objects son manejados centralmente en el sistema R/3 en el Business Object
Repository , y pueden ser llamadas desde el escritorio utilizando por ejemplo Visual Basic.
Esto significa que todas las funciones de negocio implementadas en el Repositorio son
disponibles desde aplicaciones externas.
 Ambos, módulos de función y business objects están ubicados dentro del sistema R/3. Los
usuarios deben primero entrar al sistema R/3. Este acceso puede ser automatizado.

Página 37 de 77


Noviembre, 2005

Internet Architecture
Browser

WGate

AGate
HTTP
server

R/3 application
R/3 application
Client Web host ITS
ITS server
server

R

 SAP AG

 Internet es la red global de redes de computadores. Es una plataforma estandarizada para
intercambiar datos entre individuos y organizaciones. Escenarios de Business-to-business y
consumer-to-business han sido desarrollados durante la furiosa demanda de Internet de los
últimos años, así que resultan muy útiles a la hora de conectar compañías a Internet.
 R/3 permite la conexión a Internet desde la versión 3.1G. El Internet Transaction Server
(IST) forma el principal componente de la arquitectura de Internet. Está formado por dos
componentes Application Gate (A) y Web Gate (W).

Página 38 de 77


Noviembre, 2005

EDI Architecture

Documents EDI messages Idoc type SAP documents

Control record

Daten-
Daten-
Data
satz
satz
record

Steuersatz
Steuersatz
Control record

Ext. application EDI subsystem Idoc interface R/3 application

R

 SAP AG

 EDI son las siglas de Electronic Data Interchange y describe el intercambio electrónico de
los datos estructurados de negocio entre diferentes aplicaciones
 La arquitectura EDI consta de:
• EDI-aplicaciones disponibles: Permiten procesar automáticamente las transacciones de
negocio.
• El interface IDOC: Fue concebido como una interface abierta y consiste en
documentación intermedia y sus correspondientes módulos función.
• El subsistema EDI: Convierte la documentación intermedia en mensajes EDI y
viceversa. SAP no soporta este elemento de la arquitectura EDI.
El principal componente de la interface Idoc es el tipo Idoc. Un Idoc es un estadard sap que
especifica la estructura y el formato de los datos a transferir electrónicamente. Esto fue
desarrollado teniendo en cuenta los estándares EDIFACT y ANSI X12. Los Idocs se
identifican de forma única con los registros de control. Los registros de datos forman el centro
de la aplicación. Los registros de estado graban el estado de un Idoc en su camino desde la
estructura de un S.I.SAP.

Página 39 de 77


Noviembre, 2005

Niveles de cambio

Desarrollos Mejoras Customizing
1
4 2

3
ABAP
.Programa WB Aplicaciones R/3
Propio Modificación
Exit 1

Exit 2

Software base

Software de sistema
R

 Hay cuatro formas diferentes de adaptar el sistema R/3 a las necesidades del cliente:
1) Customizing: Mediante esta vía se establecen los parámetros del cliente usando un
interfaz especial. La parametrización o Customizing es una parte obligada a la hora de
abordar una implantación.
2) Mejoras: Esto permite al cliente cambiar objetos del repositorio SAP sin usar
modificaciones.
3) Modificaciones: Las modificaciones son cambios a los objetos del repositorio de SAP.
Cuando se realiza un upgrade o se aplican parches, estos objetos se han de comparar.
4) Desarrollos propios: El sistema R/3 contiene un rango de nombre para objetos propios
del cliente, sobre el cual se pueden crear tablas, funciones, programas, etc.

Página 40 de 77


Noviembre, 2005

Mandantes en en sistema R/3 de 3 entornos
Sistema de consolidación
Sistema de desarrollo Sistema de producción

DTEST QTST PROD

SAP
Mandante
000

TMAST TMAST TMAST

 Tres sistemas de Base de datos DTEST Mandante de desarrollo y test
Desarrollo, consolidación
TMAST Mandante maestro de
Y producción test
 Testeo total de los desarrollos QTST Mandante de test en consolidación
 Se evitan restriciones a la hora de desarrollar
PROD Mandante productivo
R

 Bajo ningún concepto se han de crear desarrollos, objetos, modificaciones o mejoras en el
sistema productivo. Para dichas tareas se utilizará uno o más sistemas de desarrollo
dependiendo del ámbito del proyecto.
 La nueva funcionalidad se desarrollo en el sistema de desarrollo y posteriormente se
transporta a los diferentes sistemas. Esto asegura el trabajo diario en el sistema productivo.
 La mayoría de los clientes optan por un entorno de tres sistemas:
Esto permite testera totalmente los nuevos desarrollos, upgrades, parches, etc.
El sistema de Calidad o Consolidación, permite testear la totalidad de los transportes.

Página 41 de 77


Noviembre, 2005

Gestión de proyectos con el Workbench Organizer

o
t

Jefe de proyecto Petición de cambio

Tarea
Desarrollador

Tarea

Desarrollador
Tarea
R

Desarrollador

 Cuando comienza un nuevo proyecto de desarrollo, el jefe de proyecto crea una petición de
cambio (orden de transporte), a la cual asigna miembros del equipo de trabajo. Una
petición de cambio contiene cambios generados en un sistema. El Workbench Organizer
(WO) asigna un número a esta petición de cambio (<sid>K9<nnnnn>).
 El WO asigna una tarea para cada miembro del equipo de trabajo. Cuando un miembro del
equipo asigna un objeto a la petición de cambio, esto queda reflejado en su tarea.
 Cuando se termina todo el trabajo de la petición de cambio, cada miembro del equipo
libera su tarea. Una vez que se han liberado todas las tareas, el jefe de proyecto libera la
petición de cambio, para su posterior transporte a producción.

Página 42 de 77


Noviembre, 2005

Cerrando un proyecto

Crear objeto
Desarrollo
Asignar el objeto a una
Clase de desarrollo

Asignar el objeto
A una p. cambio
Production system
Asignación automática Bloqueo Liberar
a una tarea tarea
Liberar
Petición d. cambio

Import
Jefe de proyecto Export
Directorio R

De transportes Administrador

 Cuando los desarrolladores terminan sus tareas, las liberan. Los objetos y sus bloqueos son
pasados de la tarea a la petición de cambio.
 Cuando el proyecto está completado, el jefe de proyecto libera la petición de cambio. Los
bloqueos de los objetos en la petición de cambio, quedan liberados.
 Las peticiones de cambio pueden ser transportables o locales. El WO las clasifica
automáticamente dependiendo de su clase de desarrollo. Solo las transportables pueden ser
pasadas a producción.
 Según se libera la orden se realiza un test en modo test, que determina si va a ser posible
transportar esa orden al sistema destino.
 Los objetos de la orden son exportados al directorio de transportes.
 El resultado del export y del test import queda reflejado en el directorio de logs, para
poder ser chequeados por los diferentes consultores.
 El import al sistema destino no es automático. Lo realiza el administrador del sistema
usando el programa de control de transportes “tp”.
 Después del import se pueden chequear los logs guardados en el directorio “log”.

Página 43 de 77


Noviembre, 2005

Herramientas del ABAP Workbench
ABAP Workbench

Repository ABAP Function Screen Menu
Dictionary
Browser Editor Builder Painter Painter

Screen Painter

Menu Painter Repository
Browser

ABAP Editor ABAP Dictionary

Function Builder

R

 Las herramientas del ABAP Workbench, permiten cambiar y crear objetos del repositorio.
 El browser del repositorio proporciona un resumen de los objetos del repositorio.
 El ABAP Workbench contiene herramientas que soportan el ciclo completo para el
desarrollo de nuevas funcionalidades.

Página 44 de 77


Noviembre, 2005

Mandantes en un sistema R/3

Mandante 000

Mandante 001 Mandantes por defecto
FI
SD
Sales & Mandante 066
Financial
Accounting
Distribution
MM CO
Materials Controlling
Mgmt
PP
Production Mandante 100
TR
Treasury
Planning
R/3
QM
Quality Basis Mandante 200
PS
Project
Mandantes del cliente
Mgmt System
PM WF
Plant Main- Workflow
tenance
HR IS
Human Industry
Resources Mandante XXX
Solutions

R

 Un mandante es una unidad organizativa dentro del sistema R/3. Los mandantes tienen su
propio entorno de datos de maestro de usuarios, de datos de aplicación y parametrización.
 Los usuarios de diferentes mandantes coexisten independientemente en un mismo sistema
R/3. Los usuarios pueden ver solamente los datos del mandante en el que han establecido la
sesión.
 El mandante 000 es definido como un estándar de SAP y no debe ser cambiado por los
clientes. Este mandante se usa como plantilla para crear mandantes adicionales.
 Se pueden usar hasta 997 mandantes.

Página 45 de 77


Noviembre, 2005

 El interfaz de presentación SAPGUI (GUI = Graphical User Interface) implementa las
funciones específicas de entrada y salida del sistema R/3. El SAPGUI esta disponible para
diversas plataformas y proporciona las mismas funciones para cada una de estas. Si se ha
aprendido a manejar el sistema R/3 en una plataforma , se puede utilizar el sistema en otra
plataforma , con la excepción de unos pocos atributos del GUI, de la misma manera.
 Junto con los procesos de frontend, el SAPGUI implementa el control gráfico de los
elementos de R/3. El software de presentación de R/3 implementa el interfaz gráfico de
usuario utilizando las funciones proporcionadas por el entorno de presentación.
 El flujo de datos entre el nivel de presentación y el nivel de aplicación no consiste de
pantallas preparadas, sino de información compactada utilizando los elementos de control y
los input del usuario.
 El tamaño de los datos transferidos en cada cambio de pantalla oscila entre 1 y 2 kB.
También puede conectarse a los servidores de aplicación a través de una WAN.

Página 46 de 77


Noviembre, 2005

 Con el lenguaje de programación ABAP, se pueden utilizar los SAP OPEN SQL para
acceder a los datos de la base de datos sin interferencia con las labores de gestión de
la base de datos del sistema.
 El interfaz de base de datos de R/3 convierte las sentencias Open SQL de las sentencias
ABAP en las correspondientes sentencias de base de datos. Esto significa que los
programas escritos en ABAP no dependen de la base de datos utilizada.
 Cuando se interpretan las sentencias de Open SQL, el interfaz de base de datos de R/3
comprueba la sintaxis de estas sentencias y se asegura que los buffers locales de SAP sitos
en la memoria compartida de los servidores de aplicación, son utilizados de manera
óptima.
 Los datos que son requeridos con mucha asiduidad por las aplicaciones, son almacenados
en estos buffers, evitando así a la base de datos accesos innecesarios a disco. En particular,
todos los datos técnicos tales como programas ABAP, pantallas o información del
Diccionario ABAP, así como parámetros para la administración del negocio,
parametrización en un sistema en funcionamiento, etc, son susceptibles de bufferización.
Lo mismo se aplica a los datos transaccionales que son normalmente accedidos en modo de
sólo lectura.

Página 47 de 77


Noviembre, 2005

 Los principales componentes de un servidor de aplicación R/3 son:
 Dispatcher como centro de control de la instancia
 Cola del dispatcher para atender peticiones
 Número parametrizable de work processes para procesar los programas ABAP
 Buffers en la memoria compartida
 El manejador de tareas coordina las actividades de los work process de diálogo. Activa el
procesador de pantallas o el procesador de ABAP (qué controla el flujo lógico de las
pantallas así como de procesar las sentencias ABAP respectivamente) y ejecuta el roll-in y
el roll-out del contexto de usuario.
 La gestión de memoria del sistema diferencia entre areas de la memoria principal que son
disponibles exclusivamente para un work process, y áreas de memoria que pueden ser
utilizadas por todos los work processes. El espacio de memoria utilizado exclusivamente
por un work process tiene dos áreas reservadas para los datos específicos de sesión, que
deben de ser protegidos más allá de la duración de un paso de trabajo. Estas son las
llamadas roll y paging areas. La roll area contiene datos que son disponibles al inicio de un
paso de diálogo (rolled-in) y que son salvados al final del mismo (rolled-out). La roll área
también contiene los datos que caracterizan a los usuarios (contexto de usuario), tales
como sus autorizaciones, información de administración y datos adicionales para los
ABAP y el procesador de diálogo. Estos datos también fueron utilizados por los pasos de
diálogo ejecutados anteriormente. Hay también áreas de memoria para todos los process en
la memoria compartida para los calendarios de fábrica, pantallas, tablas y buffers de
programas.

Página 48 de 77


Noviembre, 2005

 El sistema R/3 en ejecución es un grupo de procesos paralelos y cooperando. En cada
servidor de aplicación, estos procesos incluyen desde el dispatcher hasta el número de
work process. Work process especiales pueden ser instalados para procesos de diálogo,
actualización, background y spooling.
 Además de estos tipos de work process (diálogo (D), actualización o update (V), gestión
de bloqueos (E), background (B), spool (S)), el sistema R/3 proporciona dos servicios
adicionales para las comunicaciones externas:
 El servidor de mensajes (M) establece la comunicación entre dispatchers distribuidos
del sistema R/3 , y es esencial en el funcionamiento de los servidores de aplicación que
funcionan en paralelo.
 El servidor de gateway (también llamado manejador de CPI-C) permite la
comunicación entre sistemas R/3, R/2 y aplicaciones de sistemas externos.

Página 49 de 77


Noviembre, 2005

Distribution of Business Processes with ALE

Order entry,
billing,
accounting,
inventory controlling
Head office
Shipping,
inventory Program
management planning,
Business central
Shipping unit purchasing

MRP,
CRP, SFC,
inventory Ware-
manage- house
ment management Warehouse
Plant
R

 SAP AG

 Por razones técnicas, organizativas y de negocio, puede ser necesario distribuir los
sistemas de aplicación, con el objetivo de instalarlos y operar con ellos de una manera
descentralizada.
 El concepto de ALE (Application Link Enabling) nos permite establecer y operar con
aplicaciones SAP distribuidas. ALE permite un intercambio controlado de mensajes de
negocio a través de sistemas enlazados. Las aplicaciones son integradas a través de
comunicaciones síncronas y asíncronas , y no a través de una base de datos central.
 Para establecer este modelo de sistemas integrados distribuidos, el cliente especifica en un
modelo lógico que aplicaciones deben corren en cada sistema y como se intercambian los
datos las aplicaciones.
 Los datos se intercambian utilizando IDocs (intermediate documents) desde un interfaz
EDI. EDI soporta desde el intercambio de mensajes entre sistemas R/3 de diferentes
compañías hasta el intercambio de datos en la misma compañía.

Página 50 de 77


Noviembre, 2005

 Cuando se transfieren datos de un sistema R/3 a otro, o desde un sistema heredado a un
sistema R/3 System, se debe asegurar la integridad de los datos que se transfieren.
 Como el sistema utiliza las mismas transacciones para la transferencia de datos que un
usuario de diálogo, los datos heredados son sometidos a los mismos chequeos y controles a
los que son sometidos los datos introducidos manualmente. Esto nos asegura la integridad
de los datos.
 Estos métodos utilizados para la transferencia de datos heredados, son conocidos como los
métodos de "batch input".
 Para muchas áreas del sistema R/3, SAP proporciona métodos de transferencia de datos
heredados. Estos métodos utilizan técnicas de programación batch input, call transaction y
direct input. Los métodos estándar de SAP son controlados mediante el Data Transfer
Workbench (Transaction SXDA). Si no hay métodos estándar de transferencia, se
pueden programar utilizando batch input o call transaction.

Página 51 de 77


Noviembre, 2005

 Con el batch input, los datos transferidos son bufferizados como una BDC (Batch Data
Communication) en un fichero plano (batch input session). En el siguiente paso, el sistema
procesa esta sesión, esto es, los datos son transferidos a las transacciones de aplicación
dentro del entorno del batch input, e introducidos en la base de datos.

 El sistema R/3 permite grabar una transacción en modo diálogo. Se puede utilizar esta
forma de grabación para generar una sesión de batch input y un programa de transferencia.

 Alternativamente a los batch input, se puede llamar a la transacción directamente (Call
Transaction), después un se toma un registro del fichero plano e introducido en la tabla
BDC.

 Los métodos de batch input y call transaction se pueden aplicar entre sistemas R/3. Los
datos son sometidos a los mismos chequeos de consistencia antes de su transferencia en
modo diálogo.

 Los programas de Direct input ejecutan el chequeo de consistencia y actualizan los datos
directamente en la base de datos, sin acceder previamente a las transacciones de
aplicación. Estos procesos son sólo utilizados por los programadores de SAP.

Página 52 de 77


Noviembre, 2005

Arquitectura Workplace

Página 53 de 77


Noviembre, 2005

El Workplace es la plataforma para el acceso de los usuarios a los contenidos del negocio.
 Los usuarios acceden al Workplace y a las aplicaciones que contiene utilizando el Single
Sign-On.

 El usuario puede configurar Workplace. Adicionalmente puede personalizar su Workplace
añadiéndole los links más frecuentes, así como las transacciones más utilizadas. Las
funciones de Drag&Relate están implementadas.

 El Workplace es la puerta de salida para todos los componentes del mySAP.com y para los
que no lo sean. Se puede acceder a estos componentes vía Internet o vía Intranet con un
único logon.

 La pantalla del Workplace nos permite acceder a todos los componentes del sistema. Desde
la versión 3.1I, se puede acceder a los sistemas R/3 Systems a través de Internet o de una
intranet. Los componentes típicos de mySAP.com son el Knowledge Warehouse (KW), el
Business Information Warehouse (BW), el Customer Relationship Management(CRM), el
Advanced Planner and Optimizer (APO), el Strategic Enterprise Management (SEM), el
Corporate Finance Management (CFM), y el Business-to-Business Procurement (BBP).

Página 54 de 77


Noviembre, 2005

Administración y Servicios Remotos

 Principios de seguridad en R/3

 Administración de usuarios

 Funciones del Administrador

 Computing Center Management System

 Servicios de soporte SAP

R

Página 55 de 77


Noviembre, 2005

Aspectos de Seguridad en un sistema R/3

Presentation Application
Network / Communication
Client Firewall Application
(SAPGUI) (SAProuter) server

Firewall
Firewall Internet
transaction
server (ITS) Application
Database
server
server
WEB
WEB browser
server Internet Database

R

La terminología R/3 integra varios mecanismos de seguridad a diferentes niveles:
 Red/Comunicaciones: Un firewall y un saprouter protegen la red interna. Además se
pueden integrar mecanismos adicionales de seguridad como Kerberos.
 Aplicación: El concepto de autorización evita el acceso no deseado a datos y
transacciones. Los usuarios deben identificarse con su ID y su password a la hora de
realizar el logon. El mecanismo de bloqueos de SAP R/3 evita que se realicen cambios en
los datos al mismo tiempo.
 Internet: El sistema R/3 soporta los estándares de seguridad de Internet, como por ejemplo
https.
 Base de Datos: Solo el administrado de base de datos puede tener acceso desde fuera del
sistema R/3. En este caso se aplican los mecanismos de seguridad del fabricante.
 Passwords: Existen usuarios preconfigurados en los mandantes 000, 001, y 066 después
de la instalación del sistema. Estos usuarios tienen claves por defecto y por lo tanto se han
de cambiar.

Página 56 de 77


Noviembre, 2005

El concepto de autorización

Maestro de usuarios

Perfil 1 Perfil 2 Perfil compuesto 1 Perfil compuesto 2

Autorización
Perfil x

Autorización 1 Autorización 2 Autorización x
Objeto de autorización 1 Objeto de autorización 2 Objeto de autorización x

R

 SAP AG

 El concepto de autorización es orientado a objetos. Varias unidades a proteger (centro de
coste, proveedor, etc) forman un objeto de autorización
 Para crear una autorización, se usa exactamente un objeto de autorización. El objeto de
autorización es rellenado entonces con estos valores tomando forma de autorización.
 Para reducir al mínimo el mantenimiento, se pueden combinar las autorizaciones en
perfiles de autorización. Estos se asignan a usuarios y no han de mantenerse
individualmente por usuario.
 Se pueden crear perfiles compuestos de autorizaciones y perfiles. Se suelen usar para
usuarios que han de trabajar con varios perfiles de autorización.

Página 57 de 77


Noviembre, 2005

Administración del sistema
Mostrar la lista de servidores SM51

Sesiones de usuarios SM04 AL08

Resumen de Work Process SM50 SM66
Funciones de
Administración
Entradas de bloqueo SM12

Reistros de actualización SM13

Mensajes del sistema SM02

Códigos de transaciones SM01
R

Log del sistema SM21

Página 58 de 77


Noviembre, 2005

 Las transacciones son unidades de procesamiento agrupadas en funciones que ejecutan
cambios consistentes en la base de datos. Por ejemplo creación de un material, de una
factura, de una orden de compra, etc.
 Más aún, una transacción SAP esta implementada como una serie de pasos de diálogo
conectados y consistentes. Un paso de diálogo de un usuario esta representado por una
pantalla (dynpro, que es un programa dinámico).
 Las transacciones SAP no son ejecutadas necesariamente por un único work process de
diálogo. De hecho, diferentes work processes de diálogo pueden procesar pasos de diálogo
individuales de una transacción. También se pueden utilizar actualizaciones asíncronas
para procesar la parte de diálogo de una transacción y la correspondiente actualización en
la base de datos de diferentes work processe y también en diferentes hosts.
 En un sistema R/3, un paso de diálogo empieza procesando los datos introducidos por el
usuario (PAI: Process After Input) y por procesar y enviar la siguiente pantalla (PBO:
Process Before Output); el sistema recibe entonces la siguiente pantalla procesada por el
usuario, y de nuevo analiza y procesa los datos introducidos por el usuario en esta pantalla.
Los pasos de diálogo y del sistema no tiene lugar a la vez. Para el sistema, cada media
parte del paso de diálogo se llaman respectivamente PBO y PAI.

Página 59 de 77


Noviembre, 2005

LUW (Logical Unit of Work)
Request Release
lock lock
Note changes
CALL FUNCTION
'ENQUEUE_E...'
EXPORTING CALL FUNCTION '...'
IN UPDATE TASK “Save"
COMMIT WORK

SAP LUW 1 New SAP LUW 2

Start of
transaction Start End update
update

SAP LUW 1
t

First part of the SAP LUW 1 R
Second part of the SAP LUW 1

 SAP AG

 El concepto de transacción, según se ha explicado previamente, se corresponde con el
término de Logical Unit of Work (LUW).
 Como las actuales base de datos no soportan flujos de transacciones para todos los
procesos, es conveniente diferenciar las LUW de SAP y las LUW de la base de datos
(SAP-LUW / DB-LUW). A DB-LUW es ejecutada completamente o nada . Esto asegura la
consistencia de los datos. Esto significa que los datos son lógicamente correctos antes y
después de la LUW. Esto también se puede aplicar a las SAP-LUW.
 Como en una SAP-LUW, cada paso de diálogo es ejecutado por un work process, como se
ha descrito anteriormente, por lo tanto se corresponde con una DB-LUW. Las
actualizaciones de base de datos ocurren dentro de una DB-LUW.
 La técnica predominante utilizada en las SAP-LUW es la de las actualizaciones
asíncronas. Esto significa que las peticiones de modificación del usuario son almacenadas
temporalmente, y al final de la fase de diálogo (en la segunda parte de laSAP-LUW,) la
base de datos es actualizada con un work process de update, por separado. Como en otro
paso de diálogo, esta actualización tiene lugar dentro de sus propia DB-LUW para
mantener la coherencia de los datos .

Página 60 de 77


Noviembre, 2005

Requesting a Lock

Dialog server Enqueue server

Dispatcher Dispatcher

... D-WP ... E-WP V-WP

a)

Call function Message
server b)
'ENQUEUE_E...'

Lock table in
main memory

R

 SAP AG

 Los mecanismos de bloqueos de las bases de datos relacionales no son suficientes para
manejar los objetos de negocio (tales como las órdenes de venta), y esto puede causar
efectos no deseados en muchas tablas de la base de datos. El sistema R/3 posee sus propios
mecanismos de bloqueo, que son gestionados por los work process de enqueue. Este
mecanismo de bloqueo impide el acceso concurrente a los mismos objetos.
 El work process de enqueue gestiona los bloqueos a través de una tabla de bloqueo (b)
almacenada en la memoria principal del servidor (donde corre el work process de
enqueue).
 Si un bloqueo es solicitado (a), el sistema comprueba si esta clase de bloqueo posee
entradas en la tabla de bloqueo o no. De existir entradas para este bloqueo en la tabla, la
petición de bloqueo será rechazada. De esta manera el programa de aplicación avisará a los
usuarios que no puede realizar la operación solicitada por no esta disponible la operación
solicitada.
 Como la pantalla de diálogo y el work processes de enqueue no estan ubicados en el mismo
servidor de aplicación, estos dos work process se comunican mediante message server.

Página 61 de 77


Noviembre, 2005

SAP Lock Objects

ABAP
Dictionary
Lock object
ESFLIGHT

Activate

ABAP ABAP
function module function module
ENQUEUE_ESFLIGHT DEQUEUE_ESFLIGHT R

 SAP AG

 Para que el sistema pueda atender las peticiones de bloqueo, se debe definir primero los
objetos de bloqueo en el ABAP Dictionary. El objeto de bloqueo consiste de una tabla
primaria, cuyas entradas se pueden bloquear. También se puede tenet tables secundarias
adicionales utilizando claves externas (el nombre del objeto de bloqueo definido por el
usuario debe empezar con "EY" o "EZ").
 En un objeto de bloqueo , se puede especificar el modo de bloqueo ("S" bloqueo de lectura,
"E" bloqueo de escritura). Un bloqueo de escritura (modo "E") solo puede ser activado si
ningún otro usuario ha activado un bloqueo sobre el conjunto de registros. El mismo
usuario puede borrar una entrada de bloqueo tipo "E" o "S" llamando a la rutina de borrado
desde programa.
 Si un objeto de bloqueo es activado, el sistema genera un módulo de función ENQUEUE
(bloqueador) y otro DEQUEUE (desbloqueador). Los módulos de función se denominan
ENQUEUE_<nombre del objeto> y DEQUEUE_<nombre del objecto>.
 Los bloqueos son activados y desactivados popr programas de aplicación, o utilizando
programas especiales de actualización (segunda parte de la SAP-LUW).

Página 62 de 77


Noviembre, 2005

 Los work processes pueden realizar cambios directos en la base de datos, a través del
interfaz de base de datos, utilizando para ello sentencias de base de datos.
 Con las actualizaciones asíncronas , procesando la instrucción ABAP CALL FUNCTION
'...' IN UPDATE TASK la petición de cambio es grabada en la tabla de cambios
intermedios VBLOG (c). Esta tabla de sistema salva las peticiones de modificación hechas
por el usuario dentro de la transacción SAP.
 Si el usuario cancela la transacción durante la fase de diálogo, o la transacción se termina
por otro motivo, la entrada en la tabla VBLOG no será completa, y los cambios no se
actualizarán en la base de datos.
 Los procesos de actualización son de dos tipos: V1 o actualizaciones críticas (aquellas que
no pueden ser reiniciadas en caso de error) y V2 o actualizaciones de baja prioridad
(aquellas que en caso de error si se pueden reiniciar).

Página 63 de 77


Noviembre, 2005

 La actualización es lanzada por la sentencia ABAP COMMIT WORK especificada en el
último paso de diálogo (d) de la transacción SAP.
 En la segunda parte de la SAP-LUW, el work processes de actualización (update) copia las
entradas hechas en la VBLOG (e) y actualiza los cambios en las correspondientes tablas de
aplicación de la base de datos de R/3 (f).
 Los usuarios son notificados automáticamente si una actualización (V1 o V2) es cancelada.
El sistema puede evaluar y tratar la actualización cancelada.

Página 64 de 77


Noviembre, 2005

Removing Locks
Dialog server Enqueue server

Dispatcher Dispatcher

g)
... D-WP ... E-WP V-WP

Message
server
h)

Lock table in
Main memory

R

 SAP AG

 Al final de la SAP-LUW, la actualización borra el bloqueo (g).
 Los bloqueos también son borrados si la actualización es fallida (h).
 Si una actualización es cancelada , los registros de actualización pueden ser actualizados
más tarde en la VBLOG , dependiendo del problema. Este método se utiliza para
actualizaciones V” canceladas. No se debe utilizar este método para actualizaciones V1.
SAP recomienda procesar la transacción nuevamente. (Nota OSS 16083).
 Si la base de datos cae mientras se produce un actualización , los registros de la VBLOG
que no han sido actualizados (estos tendrán status "INIT") son actualizados
automáticamente cuando se levante la base de datos. Se pueden utilizar los parámetros de
para controlar esta función del sistema.

Página 65 de 77


Noviembre, 2005

Procesando peticiones de Usuario
Presentación

SAPGUI SAPGUI SAPGUI SAPGUI

Comunicación
Applicación
Dispatcher

Work Work Work Buffer
process process process

Base de Datos Procesos de BD R

BD

 El proceso central de una instancia R/3 es el dispatcher. Junto con el sistema operativo, el
dispatcher controla los recursos de una instancia R/3.
 La entrada del usuario es recibida mediante el SAPGUI, convertida en su propio formato y
mandada al dispatcher. La petición del usuario es puesta en la cola del dispatcher y
posteriormente es procesada.
 El dispatcher distribuye las peticiones una detrás de otra a los work processes disponibles.
Los datos son realmente procesados en los work processes. No existe una asignación
usuario-work process.
 Una vez que los datos han sido procesados el resultado del work process en mandado
mediante el dispatcher al SAPGUI. El SAPGUI interpreta los datos y genera la salida por
pantalla.
 Cuando se inicializa el sistema, el dispatcher realiza las siguientes funciones: lee los
perfiles de sistema, genera las áreas de roll, arranca los work processes y se conecta al
servidor de mensajes.

Página 66 de 77


Noviembre, 2005

Proceso de fondo

Servidor de proceso en fondo

Dispatcher

D-WP 3 3
3 3 ... Servidor de dialogo
Planificador B-WP
De fondo Dispatcher

2
2
D-WP 3
3 ...
4
4 Planifica
10
11
12 1
2
1
1 trabajos
9 3
8 4
7 6 5

Job
? Job1 C ... ...

R

Tabla de planificaciones

 Los procesos de fondo se utilizan generalmente para tareas periódicas que suponen una
carga importante para el sistema.
 El proceso en fondo es planificado en forma de jobs (trabajos). Cada job consiste en uno o
más pasos (Programas ABAP o comandos externos) que son procesados secuencialmente.
Los jobs tienen prioridades de ejecución.
 Los jobs generalmente, no son arrancados en el mismo instante. Se pueden planificar
dependientes de otro job, de un evento de sistema o por hora.
 El planificador de jobs es el responsable de arrancar los jobs automáticamente. El
planificador es un programa ABAP que busca en las tablas de definición de jobs para saber
que jobs tiene que procesar.
 El planificador de jobs soporta balanceo de carga.

Página 67 de 77


Noviembre, 2005

 El balance de carga es utilizado para los procesos de background.
 Todos los jobs especificados con un servidor de destino, son ejecutados en ese servidor, y
no están sometidos al balanceo de la carga
 Los jobs a los que no se les especifica un servidor de destino, son distribuidos por los
servidores de aplicación que posean work process de batch.
 El procesamiento de los job también admite colas de prioridades. Los jobs pertenecientes a
la clase "A" tiene la máxima prioridad y se ejecutaran primero. (Secuencia: Prioridad A
con servidor de destino especificado antes que prioridad A sin servidor de destino
especificado; prioridad B con servidor de destino especificado antes que prioridad B sin
servidor de destino especificado y así).

Página 68 de 77


Noviembre, 2005

Servicios de impresión R/3
Sistema R/3

Aplicación R/3

Spool TemSe
Servidor de imp.
Servidor de imp.

Impresión Spool de
sistema
saplpd operativo
S-WP
LAN WAN LAN WAN

Spool de Spool de sistema
sistema
operativo operativo

R

 Spooling: Este término hace referencia a la transmisión de datos a dispositivos de salida
como impresoras, dispositivos de fax, etc. En grandes entorno distribuidos esta
administración es muy importante.
 El sistema de spool R/3 proporciona las ordenes de spool a impresoras y servidores de
spool, tanto a través de una LAN como a través de una WAN.
 Las ordenes de spool son generadas tanto en dialogo como en background y son ubicadas
en las base de datos de spool con los detalles de impresión. Los datos propiamente dichos
son guardados en la base de datos TEMSE (TEMporary Sequential object)
 Cuando los datos van a ser impresos, una petición de impresión es generada para una orden
de spool. Esta petición de impresión es procesada por el work process de spool.
 Una vez que el work process de spool ha formateado los datos, pasa la petición de
impresión al spool del sistema operativo.
 El sistema operativo termina el proceso de impresión.
 El sistema R/3 proporciona herramientas potentes a los administradores del sistema para
sus tareas diarias.

Página 69 de 77


Noviembre, 2005

 Estas son algunas de las funciones:
 Resumen de servidores y procesos
 Gestión de bloqueos y actualizaciones
 Creación de mensajes del sistema
 Bloqueo de transacciones
 Visualizar y analizar el log del sistema

Página 70 de 77


Noviembre, 2005

R/3 Computing Center Management System
 Control
 Administración de sistema (parada, arranque, reconfigurar el sistema)
 Gestión de los perfiles del
sistema
 Proceso de fondo y planificación de jobs
 Distribución carga
 Ajuste del sistemasystem

 Monitorización
 Control del rendimiento del sistema R/3
Base de datos y sistema operativo
 Analisis de alertas

R

 Con el CCMS se puede monitorizar, controlar y configurar el sistema R/3.
 El CCMS proporciona monitores gráficos y herramientas administrativas.
· Parada y arranque del sistema
· Monitorización y análisis del sistema R/3
· Reporte automático de las alertas del sistema
· Configuración del sistema: Perfiles del sistema, modos de operación, etc
· Procesar y controlar los trabajos de fondo, planificar backups de la base de datos, etc

Página 71 de 77

Manual c. basico sap

Manual c. basico sap

Manual c. basico sap

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente(20)

Destacado

Destacado(20)

Similar a Manual c. basico sap

Similar a Manual c. basico sap(20)

Más de ricardopabloasensio

Más de ricardopabloasensio(20)

Último

Último(20)

Manual c. basico sap