miércoles, 23 de julio de 2008

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).




    No hay comentarios: