persistency layer training

31
SAP AZUR Payment Engine Project Meeting – Persistency Layer Training May 10th, 2006

Upload: ricardo-araneda-saldias

Post on 08-Nov-2015

8 views

Category:

Documents


1 download

DESCRIPTION

GUIA

TRANSCRIPT

  • SAP AZUR Payment EngineProject Meeting Persistency Layer Training

    May 10th, 2006

  • AGENDA

    La arquitectura de Payment EngineTablesPersistency layer for customizing tablesMethodsPersistency layer for transactional tablesMethodsQ & A

  • La Arquitectura de Payment EnginePayment Engine usa una arquitectura por nivelesProcess LayerEntity LayerPersistency LayerTable

  • TablesPodemos separar las tablas de Payment Engine en dos grupos:- Tablas de Customizing (todas aquellas de tipo /PE1/T_...)- Tablas Transaccionales (las de tipo /PE1/DB_...)Las tablas de customizing contienen los datos que tienen que ser actualizados a travs de la transaccin SIMGH. Esto implica que para todas ellas hay que definir una vista con su correspondiente mantenimiento.Las tablas de datos transaccionales se actualizan a travs del proceso normal dentro de Payment Engine.La implementacin y el acceso de las clases de persistencia dependen intrnsecamente del tipo de tabla que estemos construyendo.

  • Persistency Layer for Customizing TablesAlgunos ejemplos de tablas de customizing son /PE1/T_POTYPE, /PE1/T_TRANSTYPETodas las clases de customizing tienen la nomenclatura:/PE1/CL_COMPONENT_T_NAME para CORE/PE1C1/CL_COMPONENT_T_NAME para CDPLa clase de persistencia de dichas tablas se tienen los siguientes atributos:

    S_RCL_INSTREFS_BUFFERS_FLG_TABLE_FULLY_READCON_GROWING_BUFFERCON_FULL_BUFFERCON_NO_BUFFERS_ACCESS_TYPECON_CLASSNAME

  • Persistency Layer for Customizing TablesLa clase de persistencia de dichas tablas se compone de los siguientes mtodos:

    * CLASS_CONSTRUCTOR* CONSTRUCTOR* S_INSTANCE* SET_ACCESS_TYPE* GET_ACCESS_TYPE* READ* READ_ALL* S_ON_CUSTOMIZING_CHANGED

  • Class Constructor

    SET HANDLER s_on_customizing_changed.

    Customising classes should have a method called S_ON_CUSTOMIZING_CHANGED which contains the code to clear the buffers. Across all the customizing persistency classes, these methods are registered to the event CUSTOMIZING_CHANGED. This event is currently triggered every 10 COMMIT WORKS in the system, however this will probably change so the customising is only refreshed at the beginning of a process, rather than during a process.

  • CONSTRUCTOR CLEAR: s_buffer, s_flg_table_fully_read.

    Este mtodo se llama cada vez que se crea una nueva instancia de la clase.

  • S_INSTANCEDevuelve una nueva instancia del objeto cuando no ha sido creada antes IF s_rcl_instref IS INITIAL.CREATE OBJECT s_rcl_instref. ENDIF. r_instref = s_rcl_instref.

  • SET_ACCESS_TYPE

    Asigna uno de los valores vlidos para el atributo s_access_type de forma que se controlen las opciones de buffering de acceso a la tabla

    IF i_access_type EQ con_growing_buffer OR i_access_type EQ con_full_buffer OR i_access_type EQ con_no_buffer.

    s_access_type = i_access_type.

  • GET_ACCESS_TYPE

    Recupera las opciones de buffering de acceso a la tabla

    r_access_type = s_access_type.

  • READ (Growing Buffer)

    Para growing buffer la lectura se realiza entrada por entrada. En primer lugar se chequea si la entrada requerida est en el buffer. Si no aparece en el buffer entonces se procede a su bsqueda en la base de datos y se aade dicha entrada al buffer. Si tampoco estuviera en la base de datos, entonces se lanza una excepcin.

  • READ (Full Buffer)

    Para full buffer primero se chequea que la tabla no haya sido leda anteriormente. En caso negativo se lee la base de datos y se vuelca su contenido en el buffer. Tambin debemos marcar el flag de fully_read de forma que la proxima vez no se lea de nuevo la tabla completa.En caso de que la tabla ya haya sido leida en su totalidad anteriormente, pasamos a leer directamente del buffer. Si en este caso no encontramos la entrada se lanza una excepcin.

  • Read (No Buffer)

    En caso de no tener buffer la lectura se realiza siempre directamente de la base de datos. Si no se encuentra la entrada se lanza una excepcin.

  • Read Method

    Variantes: Puede darse el caso de que la tabla de customizing utilize un buffer basado en clearing area. En ese caso el buffer se realiza por clearing area, de forma que cuando se realiza un fully buffer de una tabla se leen todas las entradas correspondientes a la clearing area que se est manejando.Existe tambin la posibilidad de tener una tabla de texto asociada a la tabla de customizing. En este caso hay que controlar que las entradas correspondientes a la tabla que han sido leidas tambin se lean.

  • READ ALL

    En este caso se devuelven todas las entradas existentes en la tabla. Por este motivo no se puede hacer distincin entre growing buffer y full buffer, ya que ambos leeran el buffer en su totalidad. Si el acceso se realiza sin buffer se leer todo el contenido de la tabla. En caso de separacin por clearing area se devolvern las entradas correspondientes a la clearing area en la que se est trabajando.

  • S_ON_CUSTOMIZING_CHANGED CLEAR: s_buffer, s_flg_table_fully_read.

  • Persistency Layer for Transactional TablesAlgunos ejemplos de tablas deson /PE1/DB_ORDER, /PE1/DB_ITEMTodas las clases de customizing tienen la nomenclatura:/PE1/CL_COMPONENT_D_NAME para CORE/PE1C1/CL_COMPONENT_D_NAME para CDPLa clase de persistencia de dichas tablas se tienen los siguientes atributos:

    S_REF_INSTREFS_BUFFERCON_COMPONENT_KEYCON_CLASSNAMES_TABLE_NAMES_TOTAL_COUNTS_COUNTER

  • Persistency Layer for Transactional TablesLa clase de persistencia de dichas tablas se compone de los siguientes mtodos:S_INSTANCES_GET_COMPONENT_KEYCLASS_CONSTRUCTORCONSTRUCTORUPDATE_XX_BUFFERINSERTDELETEUPDATEREADS_MEMORY_SYNCHLOCKUNLOCK

  • S_GET_COMPONENT_KEY

    Get component key devuelve la constante CON_COMPONENT_KEY que es la clave del componente al que pertenece la clase y la funcin que desempea.

  • CONSTRUCTOR

    Actualiza el contador de la clase y llama al mtodo UPDATE_XX_BUFFER

  • INSERT

    Se asegura de que la entrada no exista ya ni en el buffer ni en la tabla.Inserta una entrada en el buffer e incrementa el contador. Tambin rellena los datos administrativos (CRUSR, CRDAT, CRTIM). La entrada tendr un status en el buffer IEl contenido del campo GUID tambin se rellena aqu.En caso de que el contador haya alcanzado su valor mximo llama a la funcin UPDATE_XX_BUFFER.

  • UPDATE

    Se asegura de que la entrada exista o bien en el buffer o en la tabla.Actualiza la entrada en el buffer sin modificar el contador. Tambin rellena los datos administrativos (CHUSR, CHDAT, CHTIM). La entrada tendr una entrada en el buffer U.El contenido del campo GUID no se modifica.En caso de que el contador haya alcanzado su valor mximo llama a la funcin UPDATE_XX_BUFFER.

  • DELETE

    Se asegura de que la entrada exista o bien en el buffer o en la tabla.Actualiza la entrada en el buffer sin modificar el contador. La entrada tendr una entrada en el buffer D.Si la entrada ya exista en el buffer con un status I o U actualizamos el contador.En caso de que el contador haya alcanzado su valor mximo llama a la funcin UPDATE_XX_BUFFER.

  • READ

    Los mecanismos de lectura varan mucho en funcin de las necesidades y de la funcionalidad de la tabla. Normalmente estas tablas van a ser leidas utilizando largas sentencias de seleccin que permitirn busquedas concretas en la tabla. Manejarn parmetros como el tamao del paquete, gestn de lecturas de tabla y buffer, as como de lecturas anteriores.

  • S_MEMORY_SYNCH

    Maneja el evento TRANSACTION FINISHED.Limpia el buffer que hemos utilizado.

  • LOCK

    Mtodo que gestiona el bloqueo de entradas en la tabla. Para ello es necesario definir un objeto de bloqueo. Esto solo se hace cuando la tabla es transaccional. No siempre se define un mtodo aparte para el bloqueo. Segn la clase se puede hacer directamente desde los mtodos INSERT, UPDATE o DELETE.

  • UNLOCK

    Mtodo que gestiona el bloqueo de entradas en la tabla. Para ello es necesario definir un objeto de bloqueo. Esto solo se hace cuando la tabla es transaccional. No siempre se define un mtodo aparte para el bloqueo. Segn la clase se puede hacer directamente desde los mtodos INSERT, UPDATE o DELETE.

  • UPDATE_XX_BUFFER

    Mtodo manejador del evento UPDATE_XX_BUFFER.Dicho mtodo actualizar las entradas del buffer en bse de datos cuando el evento sea disparado. Dicho evento se dispara cuando el sistema realiza un COMMIT. La actualizacin se realiza de la siguiente forma:Para cada una de las posibles acciones (U, I y D), se recorre el buffer. De esta forma se llama a cada una de las funciones encargadas de realizar dicha accin para cada una de las entradas.La llamada a las funciones se realiza de forma inmediata o en UPDATE TASK en funcin del standardheader.

  • UPDATE_XX_BUFFER* check the update flag for the function call l_flg_update_task = i_rcl_standardheader->get_flg_update_task( ). * Do the desired operation to the database IF l_flg_update_task = con_no. * calling the desired function CALL FUNCTION function_name EXPORTING i_tab_data = l_tab_data EXCEPTIONS failed = 1 inconsistent = 2 OTHERS = 3. ELSE. "X, E: update task CALL FUNCTION function_name IN UPDATE TASK EXPORTING i_tab_data = l_tab_data EXCEPTIONS failed = 1 inconsistent = 2 OTHERS = 3. ENDIF.

  • Q & A