miércoles, 23 de julio de 2008

SAP/ABAP DICCIONARIO

functional areas, application areas, functional modules of R/3
Se refiere a la serie de aplicaciones de negocios integradas en R/3.
Ejemplos :
  • PP (Production Planning)
  • MM (Materials Management)
  • SD (Sales and Distribution)
  • FI (Financial Accounting)
  • CO (Controlling)
  • AM (Fixed Assets Management)
  • PS (Project System)
  • WF (Workflow)
  • IS (Industry Solutions)
  • HR (Human Resources)
  • PM (Plant Maintenance)
  • QM (Quality Management)

Transaction code, tcode,codigo de transacción.
Para entenderlo, diremos que SAP y transación es lo mismo(no es del todo cierto). Toda transacción tiene un codigo alfanumérico único.


n-tiered client/server configuración. n-nivel cliente/servidor configuración.
Se refiere a la habilidad de que una aplicación se pueda ejecutar en varios procesos/ordenadores.
La lógica cliente servidor es 2-tiered configuración pues son dos procesos los que manejan el programa.
Si el servidor es capaz de utilizar un tercer proceso (el servidor hará las veces de cliente y servidor), ya tenemos un 3-tiered configuracion.

R/3 basis.
Es una especie de run-time de R/3 que se encarga sobre todo de ejecutar los programas (interpretar).
R/2 era de tipo mainframe, y para crear R/3 de tipo cliente/servidor, tuvieron que crear este sistema.

R/3 system landscape (Entorno del sistema R/3) es el numero de sistemas de sap instalación: desarrollo,test,producción....
Recordar que un sistema R/3 es básicamente decir una base de datos (con miles de tablas).
R/2 era de tipo mainframe, y para crear R/3 de tipo cliente/servidor, tuvieron que crear este sistema.

Transacciones importantes.
SE11 para ver diseño de tablas.
SRET seleccion general de informes
SE16 browser de tablas
SU3 user profile (valores prefijados propios).
SE37 modulo funciones (en pasar a, podemos crear grupos de funciones)

Programas clientes (customer programs)
Son los programas que hacemos los mortales. Que trabajamos para clientes de SAP, luego por logica SAPERA, los programas son programas clientes.


Tablas transparentes.
Se refire a tablas que se definene en SAP y se corresponden directamente con tablas de base de datos tradicionales


Tabla pool. (Propiedad de SAP).
Pooled tabla.

Tabla pool es una tabla de la base de datos que contiene varias tablas.
Se basa en un campo llamado nombre de tabla y un campo genérico.

Una pooled tabla es una tabla 'virtual' contenida en una Tabla pool.
Las pooled tablas se manejan de forma parecida a tablas 'reales', pero en realidad se utiliza la Tabla Pool para crear/visualizar/modificar datos de la tabla.

Una Tabla Pool puede contener muchas 'subtablas'. Realmente su efectividad consiste en tener muchas subtablas y así ahorrar accesos a distintas tablas.
Las pooled tablas tienen ciertas restricciones.


Tabla cluster. (Propiedad de SAP).
Cluster(ed) tabla.

Tabla cluster es una tabla de la base de datos que contiene varias tablas.
Se basa en que las 'subtablas' tienen un índice común, y un campo genérico donde se guarda todos los datos de las 'subtablas'.

Una Cluster(ed) tabla es una tabla 'virtual' contenida en una Tabla cluster.
Las cluster(ed) tablas se manejan de forma parecida a tablas 'reales', pero en realidad se utiliza la Tabla cluster para crear/visualizar/modificar datos de la tabla.
La principal propiedad de una tabla cluster es que guarda varios registros de una 'clustered table' en un solo registro de la tabla cluster.
Una Tabla Cluster es util cuando tiene pocas subtablas pero muchos datos (registros grandes). Realmente su efectividad consiste en conseguir en un solo acceso a la base de datos a los contenidos de muchas tablas.
Las clustr(ed) tablas tienen ciertas restricciones.
Un ejemplo para entender la efectividad de estas tablas, es suponer que guardamos la cabecera y detalle de un pedido en un unico registro de la base de datos (tabla cluster). Sin embargo en sap leeremos el detalle como si estuviera en varios registros a parte de que tenemos la cabecera ya leida (pues está todo en un mismo registro).


Dominio.

En SAP un dominio es la especificación tecnica de un campo de la base de datos (o tambien de una estructura).
Se guarda en el diccionario y es reutilizable para otros campos.
Básicamente se especifica:
  • Nombre del Dominio
Comezando con (y o z)
  • Una descripción
  • Como se va a guardar en la base de datos (input):
tipo de datos (char, decimal....) su longitud y una descripción
  • Como sacaremos el dato de la base de datos(output).
con signo, sin signo....longitud.
Todo campo de una tabla o estructura del diccionario de datos tiene asignado un dominio.
Los dominios no se asignan directamente a los campos, sino que forman parte de un Elemento de Datos.


Elemento de Datos.
Un elemento de datos para SAP es la descripción semántica y técnica de un campo de una tabla o estructura.
Todo campo de tabla o estructura tiene asignado un Elemento de Datos directamente.
Se guarda en el diccionario y es reutilizable para otros campos.

  • Especificación Semántica.
Son descripciones y comentarios obligatorios para ayuda en linea sobre el campo en los browsers y aplicaciones.
  • Especificación Técnica.
Se basa en asignar un dominio.
Todo campo de una tabla o estructura del diccionario de datos tiene asignado un Elemento de datos y por lo tanto un dominio.



Grupo de funciones.
Los modulos de funciones se agrupan en grupos de funciones.
SE37
........

pbo

ABAP Runtime Environment (BC-ABA)

Process Before Output.

Block of code processed after a screen is called but before it is actually displayed.









sap, primeros pasos

http://help.sap.com/saphelp_46c/helpdata/en/fc/eb2c46358411d1829f0000e829fbfe/frameset.htm
un Dynpro es una pantalla que se puede crear en la transacción SE52 y se relacionan a un programa Z, es parecido al uso de Visual Basic. http://sap4.com/wiki/index.php?title=Dynpro



El ABAP Workbench Es un entorno de desarrollo de sap
multi-tier : Son aplicaciones cliente-servidor en las que se separan varias partes(tier,nivel). De alguna forma, han de distinguirse en el programa las partes de cada nivel (tier).
three-tier : Es una clase de multitier donde se separa presentacion-aplicacion- y datos.

(cuidado con el multi-tier, que puede tener varias interpretaciones según el contexto).

LA CAPA DE BASE DE DATOS.
Hay que distinguir el database management system (DBMS) ???
y las propias bases de datos.

Hay que tener en cuenta que la propia configuración de sap, sus ficheros y programas tambien forman parte de la base de datos.

LA CAPA DE APLICACION.
Los servidores de aplicaciones pueden estar en varios ordenadores. Esto significa que no todos los servidores de aplicaciones pueden hacer de todo(not...provide the full range of services).
Servidor de mensajes: Es un servicio que pertenece a la capa de aplicación y que permite comunicarse a los distintos servidores de aplicaciones, y tambien permite manejar los llamados grupos de servidores de aplicación y buscar el mejor lugar para ejecutar aplicaciones de un usuario (donde logear para que vaya mejor).

LA CAPA DE PRESENTACION.
Un usuario crea una sesion en el sistema R/3 y envia datos a la capa de aplicación, y recibe datos que los displaya.

OTRAS CAPAS.
Este sistema de capas puede extenderse para otros servicios y crear nuevas capas como por ejemplo:
Intenet Transaction Server (ITS).

Un Programa consta de una o mas pantallas que se rellenan(dialogos). Cada pantalla presumiblemente necesita una confirmación y un paso a un siguiente dialogo.
dialog step: Es una parte de la lógica del programa en el que el GUI ha terminado un dialogo, lo está procesando y esta parádo esperando que la capa de programa envíe una pantalla al GUI. Todo es parte de un mismo proceso o programa.
Digamos que un programa son una secuencia dialogo-dialog step-dialogo-dialog step.......final

logon
: Antes de entrar al sistema R/3, el SAP-GUI tiene que conectarse a una capa de aplicación. El SAP-GUI conecta con el servidor de mensajes del que obtiene la direción de un adecuado servidor de aplicaciones.

Con un logon se pueden abrir hasta 5 sesiones.




LA CAPA DE APLICACION.DETALLES

Work Processes
Los Work Processes son los procesos que pueden ejecutar programas. Usan una memoria compartida por todos los Work Processes. La parte de memoria que le corresponde se llama contexto(contexto is the data relevant to the current state of the program that is running). Parece ser que el numero de work processes es fijo. Estan íntimamente relacionados con las transaciones de bases de datos.
El hecho de que todos los Work Processes usen memoria compartida, necesita un mappeador de memoria muy eficiente y depurado, pero tambien minimiza las copias de memoria.
N.T Si los Work Processes son independientes ¿para que sirve tanta memoria compartida?. Quizá tenga que ver con el despachador. No lo entiendo muy bien.

El despachador
Es el proceso que habla con los SAP'GUIS, y tienen que encontrar un Work Process libre(??) para despachar las peticiones de GUI.
El número de usuarios conectados a un servidor de aplicaciones suele ser muchas veces mayor que el número de Work Processes. Además, cada usuario puede ejecutar varias aplicaciones a la vez. El Despachador tiene la importante tarea de distribuir todas las peticiones del gui entre los Work Proccesses en el servidor de aplicaciones.
(esto es mio) Gui-Despachador-Work Process y Memoria compartida:
Parte del contexto de un Work Process, se corresponde al gui original que hizo la peticion al despachador de un trabajo y este le asigno un Work Process libre. La idea de shared memory, se corresponde al contexto que ha de ser similar si el trabajo proviene del mismo gui y lo ejecuta otro Work Process, en tal caso el contexto ya existe en shared memory, y hay que direccionarlo a otro Work Process.
De todas formas, el despachador intenta hacer la asociación gui-Work Process siempre sea la misma.


Database Connection
Los work processes, cuando se les asigna un trabajo, usan una conexion a basse de datos unica y que no se puede cambiar. Un work process puede solo hacer cambios en la base de datos dentro de una unica LOW (unidad logica de trabajo).


Un Work Process es un LOW y un LOW es un Work Process por lo que un Work Process es un LOW y un Dialog Step.
Mucha shared memory, pero en principio un Work Process tiene que empezar y terminar un LOW. Esto indica que cada dialog step es un Work Process el que se encarga de procesarlo.

Tenemos un problema: Segun esto, un LOW es un dialog step, pero.... ¿Y si quermos que un programa con distintos dialog step sea una unidad de base de datos(i.e. una transacón)? ¿Podemos?.
Si porque SAP nos guarda otra sorpresa:
El modelo de programación de SAP contiene una serie de técnicas de agrupación que nos permiten agrupar actualizaciones de base de datos en unidades lógicas. La sección de un programa R / 3 que permite agrupar operaciones de bases de datos en unidades lógicas se llama SAP LUW. A diferencia de una base de datos LUW, un SAP LUW incluye todos los Dialog step en una unidad lógica, incluidas actualizaciones de base de datos.





  • Access to R/3 Repository objects (ABAP programs, screens and so on)
  • Access to catalog information (ABAP Dictionary)
  • Abap diccionary DDIC http://help.sap.com/saphelp_webas620/helpdata/en/cf/21ea31446011d189700000e8322d00/frameset.htm

    The ABAP Dictionary centrally describes and manages all the data definitions used in the system. The ABAP Dictionary is completely integrated in the ABAP Workbench. All the other components of the Workbench can actively access the definitions stored in the ABAP Dictionary.



    Project manager task
    aqui pone algo :
    http://help.sap.com/saphelp_46c/helpdata/en/2e/d9461494f911d283d40000e829fbbd/frameset.htm

    El DDIC(diccionario ABAP) forma parte del sistema R/3. Basicamente podemos pensar en en el como un supernivel de acceso a una base de datos como Oracle o Informix y que actuamos sobre el como un control remoto enviando sentencias SQL. Si creamos una definición de tabla en el DDIC, basicamente lo que hacemos es enviar la correspondiente sentencia SQL a la base de datos y crear la tabla. Lo mismo cuando modificamos la tabla.
    Pensar en el DDIC como ver y crear tablas, no como un sitio para cambiar el contenido de las tablas.




    Más sobre Work Processes

    Pues resulta que lo podemos dividir en :
    • screen processor
    • abap processor
    • database interface.
    El screen processor se encarga sobre todo del flujo del programa en sintonia con los dialogos(gui)
    El abap processor son los programas divididos seguramente en modulos y que el screen processor va llamando cuando lo requiere.
    El database interface requiere un poco mas de tiempo ver lo que hace.


    El database interface.
    Hace esto:
    • Establishing and terminating connections between the work process and the database.
    • Access to database tables
    • Access to R/3 Repository objects (ABAP programs, screens and so on)
    • Access to catalog information (ABAP Dictionary)
    • Controlling transactions (commit and rollback handling)
    • Table buffer administration on the application server.
    Open SQL VS Native SQL.

    Los programas de ABAP pueden usar secuencias Open SQL genéricas que son administradas por R/3 dbms.
    Las secuencias Native SQL se supone que son especiales para un tipo de basse de datos. No deberían usarse, el R/3 Basic usa un pequeño grupo de ellas, sobretodo para crear tablas.

    ¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿???????????????????
    BUFFER MANAGEMENT, parece querer decir que todos los WORK PROCESS esten en una o varias máquinas tienen la misma SHARED MEMORY y hay un BUFFER MANAGEMENT que se dedica a esto.
    ¿¿¿¿¿¿¿¿¿SERA VERDAD??????????
    PRESUPONGO QUE ESTOS BUFFERES SON PERSISTENTES EN EL SENTIDO QUE CUANDO UN WORKING PROCESS TERMINA, LO PUEDE DEJAR PENDIENTE PARA QUE EL SIGUIENTE LO UTILICE.

    Aquí nos esplican que se pueden guardar parte de tablas en memoria, pero hay que tener cuidado porque ¿No siempre estan actualizadas?. SUPONGO QUE SE REFERIRÁ A QUE LA TABLA SE HA PODIDO ACTUALIZAR POR OTRO LADO, Y NO SE REFERIRA AL BUFFER MANAGEMENT.

    TAMBIEN SACO COMO CONCLUSION (EN PARTE LOGICA) DE QUE HAY UNA CAPA DE PROGRAMACIÓN QUE ES DEPENDIENTE DE LA BASE DE DATOS (AUNQUE HA DE SER TRANSPARENTE AL ABAP).