Tutorial Sap 5z4t1u

/ G/ Esta sería la estructura completa de un string de conexión completo sapgui/M/sapdp01/S/3600/G/SPACE sería un ejemplo concreto del string de conexión.

Utilización de Grupos de Logon Los sistemas SAP muchas veces tienen más que sólo una o dos instancias. Cada una de estas instancias ofrece una cantidad de work processes de varios tipos y pueden acceder a los recursos de hardware. Algunas situaciones en las que las tareas a realizar en una instancia demandan una utilización intensiva del hardware, por lo tanto, degradando todo el trabajo que pueda ser realizado en esta instancia. Largos tiempos de respuesta de los procesos de diálogo son particularmente molestos para los s que se ven afectados por esto lo que lleva a costos altos debido a una pobre disponibilidad del sistema. Ejemplos de estas situaciones pueden ser: Carga debido a un gran número de solicitudes RFC externas. Carga debido a un complejo esquema de work processes de background Carga debido a numerosas tareas de update Alternativas podemos utilizar para separar las cargas de trabajo mediante los grupos de logon: Configurar un grupo de logon especial para recibir solicitudes RFC Configurar un grupo de logon especial para las actividades de background Configurar un grupo de logon especial para las tareas de diálogo Utilizar un grupo de logon para distribuir la carga de diálogo de la mejor manera SAP recomienda que en los sistemas SAP con instancias múltiples configurar un grupo de logon para las conexiones de diálogo con el objetivo de que los s experimenten tiempos de respuesta similares. Este grupo de logon es llamado por ejemplo PUBLIC. Si consideramos que es útil, podemos elegir no incluir la instancia central de nuestro sistema SAP en este grupo de logon. Por defecto, cada instancia de un sistema SAP (incluyendo la instancia central) es asignada al grupo de logon SPACE. La transacción SMLG es la que nos permitirá crear y istrar los grupos de logon en el sistema.

Lección 3: Transacciones de Análisis SM51 – Ver las instancias activas y los servicios que cada una ofrece, dando clic en el host name.

Dando clic en el botón Release Notes podemos observar la versión del Kernel

Para pasar a la transacción sm04 podemos dar clic en el botón de s para ver que s se encuentran logueados en la misma instancia

Podemos observar las sesiones del , seleccionamos el y damos clic en el botón Sessions.

Podemos cerrar alguna sesión del .

La transacción al08 es informativa, podemos observar los s que se encuentran logueados.

La transacción sm50 muestra una vista de procesos,

Podemos modificar el nivel de trace para un work processes determinado.

En la transacción sm21, podemos visualizar diferentes tipos de eventos registrados por el sistema,

El nivel de prioridad identifica donde sucedió un problema

La transacción st22, nos permite ver los errores en tiempo de ejecución programas ABAP

de los

La información recopilada por el sistema luego de que ocurre el error, se divide en diferentes áreas de vista para ser visualizada por el , el programador o por el del sistema.

La transacción sm02 es utilizada para crear mensajes para ser visualizados por el del sistema, son visto por el cuando cambia de transacción.

Lección 4: Inicio y parada del sistema SAP.

Lección 5: Logs de Inicio del sistema Problemas ocurridos durante el inicio del sistema SAP deben ser analizados por el del sistema. Los archivos de log y trace generados son de gran ayuda para identificar la causa. Registrando el Proceso de Inicio El proceso de inicio es una fase especialmente importante, el cual es registrado por el sistema operativo, el sistema SAP y la base de datos.

Si el sistema SAP no inicia, podemos encontrar mensajes de error pertinentes en los archivos de log. Podría ser por ejemplo que existan problemas iniciando la base de datos, lo que significa que el sistema SAP no podría ser iniciado.

Figura 42 – Registrando el Proceso de Inicio del Sistema SAP

Los logs sobre el proceso de inicio del sistema SAP se almacenan en el file system. Si hay problemas durante el inicio, estos logs pueden proveer información muy útil tal como mensajes de error o descripción de problemas. Estos archivos están en el directorio local (DIR_HOME) de la instancia respectiva. Durante el proceso de inicio, los archivos de log STDERR son creados por el Servicio de SAP. Los procesos de inicio escriben cada uno de estos archivos, dependiendo de la secuencia en la que estos componentes están listados en el perfil de inicio de la instancia (start profile). El contenido de estos archivos de log por lo tanto depende de la configuración individual del sistema, y podría, por ejemplo, ser como sigue: STDERR1: Información sobre el proceso de inicio del sistema de base de datos. STDERR2: Información sobre el proceso de inicio del message server. STDERR3: Información sobre el proceso de inicio del dispatcher. Puedes configurar el nivel de detalle de la información registrada en cuatro niveles diferentes a través del parámetro de perfil rdisp/TRACE. Los posibles valores para este parámetro son: 0: 1: 2: 3:

Solamente errores Errores y advertencias (por defecto) Mensajes de error y resumen de traza (trace) Mensajes de error y traza completa

Cuanto más alto el nivel de traza, más grande la cantidad de información registrada, y por lo tanto mayor el tamaño de los archivos generados. En conclusión, deberíamos incrementar el valor por defecto sólo por períodos cortos para el análisis de problemas. El nivel de traza puede ser configurado por separado para cada work process en la vista de procesos (Transacción SM50).

Figure 43 - Análisis de Problemas

Si el sistema SAP no inicia correctamente, esto puede ser debido a una variedad de razones. Para analizar el problema, podemos proceder de la siguiente manera: Verifica los mensajes de error y advertencia en el sistema operativo con las herramientas correspondientes del mismo. Verifica el status de la base de datos respectiva utilizando los archivos de log de errores. (Puedes encontrar más información en la lección: Apéndice: Logs de Base de Datos) Verifica el log de inicio en la consola de SAP (SAP MC). Selecciona la instancia que está con problemas, y desde el menú de contexto, selecciona List Developer Traces (Listar Trazas de Desarrollador) Verifica los archivos de error stderr que fueron creados por el Servicio de SAP. Verifica los trace files (archivos de traza) individuales de los work processes: dev_ms: developer trace (traza de desarrollador) del Message Server. dev_rd: developer trace del Gateway. dev_disp: developer trace para el dispatcher dev_wm: developer trace para los work processes (m es el número de ID de work process que vemos en la transacción SM50). Si aún puedes loguearte al sistema SAP, verfica el log del sistema utilizando la transacción SM21.

Lección 6: Apéndice - Logs de Base de Datos. En algunas ocasiones, frente a un error con nuestro sistema SAP, deberemos acceder a los logs de la base de datos sobre la que está instalado el sistema. 1| Max DB

Figura 44 – Logs de Max DB

Los mensajes de sistema y errores son registrados por Max DB en el siguiente directorio: :\sapdb\data\wrk\<SID> Donde <SID> es el nombre de nuestra base de datos, la cual coincide con el del sistema SAP. Los mensajes de sistema son registrados en el log del Kernel (knldiag). Este contiene los siguientes tipos de mensaje en un orden cronológico: Inicio y parada de la base de datos. Información sobre las áreas físicas de almacenamiento. Procesos de s. Mensajes de error de sistema El log se escribe con una modalidad conocida como anillo o circular, lo que significa que es sobreescrita cada vez que alcanza un cierto tamaño. Un nuevo archivo de log es creado después de cada inicio del sistema de base de datos. Una copia del log anterior (knldiag.old) se crea antes de reiniciar el sistema de base de datos. Todos los mensajes de error y advertencia relativos al sistema de base de datos son registrados en el log de errores (knldiag.err), incluyendo los mensajes para el inicio y parada de sistema.

2| MS SQL Server

Figura 45 – Logs de MS SQL Server

MS SQL Server registra todos los eventos significativos tales como los de inicio y parada de la base de datos y mensajes de error en el archivo: :…\MSSQL\LOG\ERRORLOG Una nueva versión del archivo de log de errores es creado con cada inicio del MS SQL SERVER. Las versiones de estos archivos de logs se almacenan en el órden ERRORLOG.1, ERRORLOG.2 y así sucesivamente. La versión más vieja se almacena como ERRORLOG.6. En cada reinicio del SQL Server, el archivo más antiguo (ERRORLOG.6) se sobreescrito y los demás se renombran para mantener el órden mencionado. Estos archivos de logs pueden ser visualizados utilizando la herramienta del sistema MS SQL SERVER: Enterprise Manager o Management Studio dependiendo la versión. Los mensajes registrados por el servicio SQLServerAgent también se almacenan en la misma ubicación con el nombre de archivo SQLAGENT.OUT. Las últimas seis versiones de este log también son guardadas. 3| ORACLE

Figura 46 – Logs de Oracle

La base de datos Oracle registra todos los eventos significativos tales como el inicio y parada de la base de datos y mensajes de error en el archivo: :\oracle\<SID>\saptrace\background\ALRT.LOG. Información detallada sobre errors se registra en el archivo de traza de Oracle (Oracle trace file): :\oracle\<SID>\saptrace\trace\Ora<no>.trc. Si el del sistema istra la base de datos con el sapdba, este escribe sus propios archivos de log en los siguientes directorios: :\oracle\<SID>\sapreorg :\oracle\<SID>\sapcheck :\oracle\<SID>\sapbackup 4| DB2 (UDB)

Figura 47 – Logs de DB2

La base de datos DB2 registra todos los eventos significativos en el archivo db2diag.log. La ruta bajo la cual este archivo estará almacenado se define con el parámetro Diagnostic Directory Data Path (DIAGPATH). Esta ruta se configura en el Database Manager Configuration. El valor por defecto es : $DB2INSPROF/DB2INSTANCE. El archivo db2diag.log contiene la siguiente información: El lugar en el cual el error ha sido reportado. Los IDs de la aplicaciones permiten la comparación entre entradas que pertenecen a una aplicación particular tal como SAP en el archivo db2diag.log Un mensaje de diagnóstico con la razón del error. El mensaje usualmente comienza con “DIA”. Toda la información disponible tal como la estructura de datos SQLCA y punteros a otros archivos de dump o trap. Información detallada sobre los errores se registra en los archivos de traza (trace) o volcado (dump) DB2, los cuales también se almacenan en la ruta definida por el

parámetro DIAGPATH. Estos archivos son solamente creados si un problema serio interno de DB2 ocurre. Podemos acceder al directorio de volcado mediante la transacción DB6COCKPIT y seleccionando Diagnósticos –> Directorio de Volcado en el área de navegación. Si lo que queremos es mostrar el contenido de un log de error o un archivo de traza, solo necesitamos hacer doble click sobre el archivo. 5| Informix

Figura 48 - Logs de Informix

Todos los eventos significativos, tales como inicio y parada de la base de datos y mensajes de error son registrados por INFORMIX en el archivo: $INFORMIXDIR/online. .<SID>.formación detallada de los errores se registra en el archivo de traza (trace file) af. En ciertas ocasiones, el contenido de la memoria compartida es copiada a los archivos shmem. El directorio en donde estos archivos son almacenados se define utilizando el parámetro DUMPDIR. El valor por defecto de este parámetro es /tmp.

Mantener el sistema y la base de datos Lección 1: Evaluación de parámetros SAP En muchas ocasiones, ya sea porque necesitamos resolver algún problema o porque nos gustaría realizar ajustes en el sistema para mejorar la performance del mismo tendremos que evaluar y mantener los parámetros del sistema SAP. Configuración de los Parámetros del Sistema La configuración de las instancias y por lo tanto del sistema SAP se realiza usando los parámetros del sistema. Los valores por defecto para estos parámetros son definidos en el código de programa del kernel del sistema.

Figura 49 – Asignando los Parámetros del Sistema

La figura muestra los lugares donde están definidos los parámetros del sistema y la secuencia de lectura de los mismos. También podemos observar que existe una prioridad o peso del parámetro dependiendo de dónde lo definamos. Esto significa que un parámetro que tiene un valor definido por defecto en el kernel del sistema, cuando está definido en el perfil DEFAULT.PFL tomará el valor de este último, y si está definido también en el perfil de la instancia, entonces será ese valor con el que finalmente funcionará el sistema. Podemos cambiar los valores por defecto de los parámetros utilizando los archivos de perfiles, los cuales son leídos cuando las instancias del sistema se levantan. Estos archivos de perfiles son creados durante la instalación del sistema y pueden ser editados luego. Como los archivos de perfiles son solamente leídos cuando inicia el sistema, necesitamos reiniciar la instancia o el sistema completo después de cambiar algún parámetro. El dynamic switching (cambio dinámico) de parámetros, el cual se realiza mientras el sistema se encuentra operando, es posible para un pequeño grupo de parámetros del sistema.

Figura 50 – Archivos de Perfiles a nivel del Sistema Operativo

Los archivos de perfil son automáticamente creados durante la instalación. Después de que se completa la instalación, los archivos de perfiles son almacenados a nivel del sistema operativo en el directorio: usr\sap\<SID>\SYS\profile Este directorio puede ser leído por todas las instancias de un sistema SAP utilizando las técnicas de montaje o de directorio compartido dependiendo el sistema operativo por supuesto donde esté instalado el sistema. El sistema SAP tiene tres perfiles de sistema. Estos son: Start Profile (Perfil de Inicio) Default Profile (Perfil por Defecto) Instance Profile (Perfil de Instancia) Visualización de los Parámetros En principio, podemos cambiar estos archivos con herramientas de edición del sistema operativo. Quienes editen estos archivos, deben asegurarse que los cambios realizados sean correctos ya que si son configurados de manera incorrecta pueden llevar a que el sistema no inicie. Es mucho más conveniente y seguro realizar los cambios de los parámetros de perfiles utilizando las herramientas en el sistema SAP.

Figura 51 – Archivos de Perfiles (Profile Files)

El perfil específico por instancia de inicio, cuya nomenclatura es: START <nombre de servidor> especifica que procesos van a iniciar por cada instancia estos procesos son por ejemplo el MS y dispatcher. Existe solo un único pefil por defecto, cuyo nombre es DEFAULT.PFL, por cada sistema SAP y el cual es leído por todas las instancias SAP. Contiene configuraciones que afectan a todo el sistema, tal como el nombre del sistema, el nombre del servidor de base de datos o el cliente de logon por defecto para el sistema.

El perfil de instancia, <SID>_ _<nombre de servidor> define parámetros que aplican para una instancia, tales como el número y tipo de work processes, o la definición del tamaño de área de memoria principal asignada al sistema SAP. El perfil de la instancia es por lo tanto específico por instancia.

Figura 52 – Visualización de Parámetros del Sistema

Los valores actuales de los parámetros del sistema pueden visualizarse en el sistema. Para esto, podemos optar por dos maneras: el reporte RSPFPAR y la transacción RZ11. Ambas funciones muestran los parámetros para la instancia en la que el se encuentra logueado. El reporte RSPFPAR muestra una lista de todos los parámetros específicos de instancia, y de los parámetros que aplican para todo el sistema también. Esta lista se puede acotar a un rango específico de parámetros. El resultado es una tabla donde se muestra por cada parámetro los valores por defecto del sistema tal como están definidos en el programa del kernel y si el valor por defecto ha sido anulado por un valor definido por el ya sea en el perfil por defecto o en el específico de la instancia, se mostrará este valor también. Una breve descripción y, si se requiere, documentación para los parámetros puede ser visualizada también.

Figura 53 – Reporte RSPFPAR

La transacción RZ11 muestra información y documentación para los parámetros de forma individual. También muestra con el indicador Conmutación Dinámica (Dynamically Switchable) si el parámetro puede tomar un cambio de inmediato sin tener que reiniciar el sistema.

Figura 54 – Transacción RZ11

Cuando modificamos un parámetro utilizando la transacción RZ11, la modificación se mantendrá mientras la instancia esté activa. Una vez que reiniciemos la instancia el valor del parámetro volverá al que estaba definido previamente ya sea del kernel o del perfil de la instancia. Modificar parámetros que tienen la propiedad de conmutación dinámica en la transacción RZ11 es útil para realizar pruebas sin tener que reiniciar la instancia o el sistema enteramente. Luego, si decidimos que el cambio debe ser permanente lo haremos utilizando la herramienta de mantenimiento de parámetros, transacción RZ10. En la tabla TPFYPROPTY, todos los parámetros que pueden ser cambiados dinámicamente están identificados con el indicador Dinámico (Dynamic). Puedes utilizar la transacción SE16, por ejemplo, para visualizar esta tabla. Fuera del sistema SAP, podemos visualizar los parámetros a nivel del sistema operativo si estamos trabajando con el <SID> con el programa sappfpar. Podemos obtener el valor actual de un parámetro con el comando sappfpar . El comando sappfpar all devuelve una lista de todos los parámetros. Podemos verificar que parámetros están configurados utilizando sappfpar check. El comando sappfpar help devuelve una breve ayuda sobre las posibles opciones de ejecución del programa. También es posible especificar un perfil de instancia, un número de instancia o el nombre del sistema SAP con este comando si utilizamos las opciones pf=ruta y nombre del perfil de la instancia, nr=número de la instancia o name=SID

Para la evaluación de los parámetros de perfiles utilizando las herramientas descriptas, algunos parámetros de perfiles son los mismos para todo el sistema mientras que otros serán diferentes por cada instancia. El reporte RSPFPAR muestra la configuración de la instancia en la que se ejecuta el mismo.

Lección 2: Mantenimiento de parámetros SAP

Lección 3: Configuración de Modos de Operación

Lección 4: Tareas relacionadas a la base de datos de SAP Esta primera lección de tres, describe de una manera simple la arquitectura y funcionalidad de las bases de datos relacionales. Basándonos luego en este conocimiento, veremos cómo realizar las actividades primarias de la base de datos mediante la planificación en el calendario de base de datos, transacción DB13. Fundamentos de istración de Base de Datos Un sistema de base de datos (Database Management System: DBMS) incluye procesos de base de datos, un buffer en la memoria principal, data files (archivos de datos) que contienen la información, y log files (archivos de registro) donde los cambios a la información son registrados. Cuando el sistema SAP inicia, todos los work processes se conectan a un proceso de la base de datos. Las consultas a la base de datos pasan de los work processes de SAP a los procesos de base de datos asignados, los cuales ejecutan la solicitud en la base de datos.º Los datos se almacenan en los data files, el a los datos siempre se realiza mediante la utilización del buffer en la memoria principal. Procesos especiales de la base de datos se encargan del intercambio de datos entre el buffer y los data files. Durante este intercambio, los datos se leen y se escriben siempre en páginas completas, las cuales normalmente contienen cientos de registros de datos.

Figura 55 - Conceptos de Base de Datos

Si se realizan cambios a los datos, estos son registrados en el log file, por lo tanto el archivo contiene el estado de los cambios realizados a la base de datos. Solo los cambios, pero no las páginas completas, se registran en el buffer de log. Las entradas se escriben desde el log buffer al log file, el cual puede ser sólo uno o más de uno dependiendo de la base de datos.

Para cada base de datos, existe un mecanismo que realiza un backup (respaldo) de la información desde el log file a otros archivos o a un medio de backup. Esto asegura que el archivo de log no se vuelva demasiado grande porque con cada respaldo del log file, el espacio ocupado por la información respaldada es liberado por el sistema de base de datos para ser reutilizado y registrar nuevos cambios a la base de datos en el log file. SAP recomienda que realicemos un espejado del archivo de log. Algunas bases de datos proveen un software especial que realiza el espejado de los archivos. El espejado de log file mediante este software especial se realiza mediante una escritura de dos log files en paralelo (primario y secundario). El sistema de base de datos puede solamente sobrescribir los archivos de log primario y secundario una vez que el primario ha sido respaldado (backup). Cuando hay problemas para acceder a un log file primario, el archivo es marcado como defectuoso, y la base de datos debe llevarse a un estado operacional OFFLINE. Para restaurar el log file defectuoso, es necesario reemplazarlo completamente con el contenido del log file secundario. El mecanismo de log no debe ser desactivado nunca en un sistema productivo; de otra manera el estado de las modificaciones a los datos podría perderse ante una falla. Esto significa que habría un riesgo alto de pérdida de datos ante una destrucción del disco duro de los archivos de datos de la base. Un sistema de base de datos siempre incluye datos estructurados que contiene información esencial de la base de datos, tal como el número de data files.

Lección 5: Backup y Recuperación de la base de datos Esta lección muestra los conceptos sobre el respaldo de la base de datos. Estos conceptos incluyen un backup regular de datos y de la información de log. Estos backups son realizados mediante el calendario de planificación de base de datos, transacción DB13. Para proteger el sistema SAP contra la pérdida de información si un error ocurre, el regularmente realiza los backups. Concepto de Backup El concepto de backup para la base de datos siempre incluye un backup regular de los data files, la información de log y los datos estructurados de información de la base de datos misma. El backup de los data files y la información de log se realiza en pasos diferentes. Todos los data files y los datos estructurados son respaldados en un solo paso. En otro paso, la información de log se respalda de forma separada.

Figura 56 – Backup de Data Files e información de Log

Se pueden planificar ambos pasos en un sistema SAP (excepto en una plataforma AS400) como acciones regulares utilizando el calendario de planificación de base de datos, transacción DB13.

Escenarios para la Recuperación de una Base de Datos Si es necesario realizar una recuperación de la base de datos, el momento al cual podremos recrearla de manera consistente dependerá no solamente de la disponibilidad del backup de data files con el que contemos, sino también de la disponibilidad de los backups de información de log con la que contemos. Si un backup de data files se pierde o está corrupto, una recuperación puede basarse en el último backup válido de data files y luego recuperarla a un punto más reciente en el tiempo, si los respaldos de información de log están disponibles sin ningún faltante. Esto significa que tenemos que contar con todos los backups de información de log que se realizaron a partir del backup de data files que utilizamos para la recuperación hasta el punto en el tiempo que necesitemos recrear la base de datos. Recuperar la base de datos (con pérdida de datos) Observando la figura 462, si un accidente del disco duro ocurre en un punto entre t1 y t2, todos los datos respaldados en el backup de data files t1 son recreados con la recuperación. Si ninguna acción se realiza luego de esto, todos los cambios a la información (creación, modificación o borrado) que fueron realizados después del punto t1 se perderán.

Figura 57 – Recuperación con pérdida de datos

Recuperar la base de datos (sin pérdida de datos) Todos los datos del backup de data files t1 son recuperados. Algunas bases de datos permiten recuperar solamente los data files que faltan o inclusive objetos específicos de la base de datos como por ejemplo una tabla determinada. Luego, toda la información de log consecutiva respaldada desde el punto t1 (22,23,…) son tomados para la recreación de la base de datos. En el último paso, el archivo de información de log que tenía la base de datos hasta el punto del accidente es recuperado. Esto significa que toda la información ahora está en el mismo estado hasta el punto en el que ocurrió la falla del disco duro. Solamente si toda la información de log desde el último backup de data files está disponible, sin faltantes, la recuperación de la base de datos será sin pérdida de datos.

Figura 58 – Recuperación sin Pérdida de Datos

Almacenando los backups de data files e información de log La información de log respaldada en los backups es borrada a nivel del sistema operativo para evitar problemas de espacio en disco. Si un accidente de disco ocurre en el punto t5 de la figura 463, y un medio de backup del backup de data files t3 se encuentra defectuoso, un backup anterior en el tiempo (en este caso, t1) debe ser utilizado. Para recuperar la base de datos sin pérdida de información, es absolutamente necesario contar con todos los backups de información de log (en este caso t2 y t4) que se generaron luego del backup de data files en el punto t1. Por esto es necesario mantener siempre backups de data files e información de log más antiguos del último backup de data files. Otras consideraciones: Algunas base de datos también requieren de la información de log para poder realizar una recreación de la base de datos. Por lo tanto deberíamos asegurarnos que se realicen backups tanto de data files y la información de log regularmente. Ciclo de Backup Hay diferentes variantes para un completo backup de data files diario, dependiendo de la base de datos. Al menos un backup online debería realizarse de la base de datos, con un subsecuente backup completo de información de log. Los medios de backup utilizados pueden ser sobrescritos nuevamente cada 28 días. Esto es una recomendación. Los backups podrían ser retenidos por mucho más tiempo en una compañía. SAP recomienda que la duración de un ciclo de backup sea de 28 días. Esto significa que los backups de data files e información de log son sobrescritos después de 28 días, al menos.

Figura 59 – Ciclo de Backup Recomendado

En un sistema productivo SAP recomienda realizar un completo backup de datos diariamente. Algunas bases de datos ofrecen la opción de realizar backups diferenciales o incrementales de data files, lo que no realiza un completo backup de la base de datos (estos backups serán referidos como backups parciales de ahora en más).

Si se utiliza un backup parcial de datos como estrategia diaria de backup, se debería realizar un backup completo al menos una vez por semana. Debería haber al menos cuatro backups completos de la base de datos contenidos en un ciclo de backup. La información de log debería respaldarse al menos una vez por día. También es recomendable duplicar los medios de backup para la información de log para asegurar que contamos con todos los backups de log en caso de que alguno se encuentre defectuoso. En muchas compañías generalmente se realizan backups de la información de log más de una vez por día con frecuencias de hasta 30 minutos. Esto dependerá muchas veces de la cantidad de información que se modifique en la base de datos durante el día lo que impacta directamente en un crecimiento de la información de log. Por último es recomendable realizar un backup de data file e información de log con verificación al menos una vez en el ciclo. Esto asegura que el backup es legible en el dispositivo de backup, pero incrementa el tiempo total del respaldo de la información.

Planificación y Monitoreo de Backups En el sistema SAP, puedes planificar y monitorear backups regulares con la transacción DB13.

Figura 60 – Transacción DB13

Figura 61 – Planificación de Backup

Si por ejemplo utilizamos un medio externo como un dispositivo de cinta, deberemos verificar que medio se requiere para el próximo backup cada día e insertar el medio (cinta) correspondiente antes de iniciar el backup. Verifica diariamente si los backups se han completado satisfactoriamente. En el calendario de planificación, un backup exitoso se muestra en verde o amarillo (cuando hay alguna advertencia). Si el indicador es de color rojo, entonces un error sucedió durante la ejecución del backup, por lo tanto es inutilizable.

Figura 62 – Código de colores de estado de tareas.

Información adicional se puede ver en la transacción DB12, la cual nos permite visualizar los registros de sucesos de las actividades realizadas en la base de datos.

Figura 63 – Transacción DB12 ½

Esta transacción además del listado de registros, nos permite visualizar las áreas de datos y log utilizadas por la base de datos.

Figura 64– Transacción DB12 2/2

A partir de la versión SAP Web Application Server 6.10, es posible controlar y monitorear los backups para todos los sistemas del landscape con el calendario de planificación central, transacción DB13C. La planificación se transfiere a los sistemas remotos utilizando una conexión de tipo RFC. DB13 fue mejorada para la versión SAP Netweaver 7.00, lo que permite utilizar la misma para planificar acciones en otras bases de datos. Para poder realizar esto, primero es necesario crear las conexiones a estos sistemas en DB13. El botón de documentación sobre las tareas que son recomendaciones.

posibles

, nos puede dar mayor información realizar desde la transacción DB13 y

Lección 6: Monitoreo de base de datos Dependiendo de la base de datos que se utilice para el sistema SAP, existe una cantidad de verificaciones periódicas que deben llevarse a cabo adicionalmente a la realización de los backups. Para asegurarnos una óptima performance de la base de datos y por lo tanto, una buena performance del sistema SAP, el debe realizar verificaciones adicionales a la base de datos, las cuales pueden ser planificadas regularmente.

Monitoreo Regular de la Base de Datos Además de los chequeos de la ejecución de los respaldos de la base de datos, existe una serie de verificaciones que podremos realizar mediante la transacción DB13 también.

Figura 65– Monitoreo de Base de Datos

Estas verificaciones, incluyen entre otras: Generación de estadísticas para asegurar una buena performance cuando se accede a los registros. Crecimiento de la base de datos y espacio disponible Chequeo de errores o problemas generales de la base de datos La generación periódica de estadísticas es un importante prerrequisito para un eficiente a los registros. Cuando una sentencia SQL es ejecutada, la base de datos tiene que optar por una de las posibles alternativas para acceder a los datos requeridos. En la sentencia SQL, la condición WHERE especifica el número de registros que se obtendrán para la consulta. La base de datos debe encargarse ahora de obtener la información tan rápido como pueda, en otras palabras, en la menor cantidad de s posibles. La base puede leer el contenido completo de una tabla, lo que se denomina Full Table Scan o acceder a una tabla a través de un índice (index scan). Utilizando las estadísticas, el Optimizador Basado en Costo (Cost Based Optimizer) de la base de datos calcula el de lectura respectivo para todas las posibles alternativas y elige el mejor (el más económico) camino de .

Figura 66 – Determinando el Mejor Camino de

Actualización de Estadísticas Las estadísticas contienen información sobre el número de entradas en la tabla, el número de bloques que son ocupados por la tabla y el índice de la tabla y la selectividad de los registros según los valores de los campos. La duración recomendada para la generación de las estadísticas puede variar dependiendo de la base de datos que utilicemos o de la versión. En principio, la actualización de estadísticas solo tienen que ser generadas cuando una tabla ha crecido o reducido notablemente su tamaño. Esto es porque la generación de estadísticas en el entorno SAP se ejecuta en dos pasos:

En el primer paso, un chequeo es realizado para determinar si es necesaria la generación de estadísticas para la tabla. Para hacer esto, el número actual de registros de datos se compara con el número de registros de datos que existían la última vez que se ejecutaron las estadísticas. En el segundo paso, las estadísticas son generadas para todas las tablas para las cuales su tamaño ha cambiado de manera considerable. Dependiendo de la base de datos que se use, ambos pasos son planificados en la transacción DB13 en un único job o en jobs separados. La generación de estadísticas es sumamente importante para el eficiente a los datos y debería ser verificado regularmente por el .

Monitor CCMS Otra tarea importante del además de asegurar el eficiente a la base de datos es verificar el crecimiento de la base de datos, en particular el espacio libre disponible para la base. Esto se puede realizar utilizando las herramientas propias de la base de datos o desde el mismo sistema SAP. La Figura 67, muestra una sección del monitor de base de datos que puede ser utilizado para monitorear que tan llena está la base de datos. Como muestra la Figura 67, se puede monitorear no solamente el fill level (nivel de llenado) de la base, sino también la performance y las actividades planificadas tales como el backup y la generación de estadísticas.

Figura 67 – Monitor CCMS: Base de Datos.

La transacción DB02 nos permite realizar un análisis del estado de la base de datos, donde podemos verificar entre otras cosas el tamaño total de la base de datos y el espacio ocupado realmente o estadísticas de las tablas e información sobre tablas o de índices perdidos así también como el nivel de llenado histórico.

Figura 68– Análisis de Base de Datos (DB02)

DBACOCKPIT La transacción DBACOCKPIT concentra todas las operaciones y funciones de monitoreo para la base de datos. En vez de tener que llamar a cada una de las transacciones que vimos anteriormente podemos acceder directamente a la transacción DBACOCKPIT y desde allí realizar todas las tareas necesarias para la istración de la base de datos.

Figura 69 – Transacción DBACOCKPIT

s, Roles y Autorizaciones Lección 1: Concepto de istración de s ABAP Los s de los sistemas SAP requieren contar con las autorizaciones apropiadas para ingresar al sistema. El crea y configura un ID de en el sistema para cada .

Bases de istración de s El concepto de registro maestro de y el concepto de autorización serán explicados con mayor detalle abajo. Ambos conceptos son muy importantes para comprender mejor los sistemas SAP.

Figura 70- s en el ambiente SAP

El término generalmente se utiliza para hacer referencia a una identificación de (ID de ). La gente se loguea a un sistema operativo, una base de datos o a un sistema SAP utilizando un y contraseña válidos. Los sistemas operativos, las bases de datos y el sistema SAP usualmente tienen diferente conceptos de autorización. Si una combinación de y contraseña es creada en un sistema SAP para una persona, esto no significa que es posible para esa persona loguearse en el sistema operativo del servidor con el mismo y contraseña. De todas formas, es posible que una combinación idéntica de y contraseña se creen para loguearse al sistema operativo y al sistema SAP. Las solicitudes de los s son procesadas por los work processes de SAP. Estos work processes utilizan un mismo para acceder a la base de datos. Los datos de s y autorizaciones son dependientes del cliente. El a nivel del sistema operativo de un servidor de aplicación SAP y del servidor de la base de datos deben ser protegidos o la operación y los datos del sistema SAP pueden ponerse en riesgo. Autorizaciones

Figura 71– s y Autorizaciones

La protección de autorizaciones se realiza en dos niveles: 1- ¿Puede una transacción ser accedida? 2- Autorizaciones para realizar acciones y tratamiento de datos durante el uso propio de la transacción. Una persona puede loguearse a un cliente de un sistema SAP si conoce la combinación de y contraseña. Si el luego intenta iniciar una transacción para la cual no tiene autorización, el sistema rechaza al con un mensaje de error apropiado. Si el inicia una transacción para la cual tiene autorización, el sistema muestra la pantalla inicial de la transacción. Dependiendo de la transacción que haya ejecutado, el ingresa datos y realiza acciones en la pantalla. Verificaciones adicionales de autorización se llevan a cabo para los datos y acciones que se realizan para proteger los mismos. A los s se les asignan autorizaciones mediante roles. Las autorizaciones son combinadas en roles y los roles luego se ingresan en el registro maestro de . Esto se explica con mayor detalle en las próximas lecciones.

Figura 72 – Registro Maestro de .

Tipos de s El tipo de es una propiedad importante de un . Diferentes tipos de existen para diferentes propósitos: Diálogo Un normal de Diálogo se utiliza para todas las formas posibles de logón por una persona. Durante un logón de diálogo, el sistema verifica si la contraseña es inicial o expiró entonces el tiene la oportunidad de cambiar su contraseña. También el sistema verifica si múltiple sesiones son creadas con el mismo y si permite que el decida qué hacer en los casos que sea posible utilizar múltiples sesiones.

Sistema El tipo de Sistema se utiliza en comunicaciones dentro de un sistema o para procesamiento de fondo. Este tipo de no puede utilizarse para acceder mediante el programa SAP GUI o ningún otro método que pueda utilizar una persona, podemos decir que no es interactivo. También se puden usar los s de tipo Sistema para aplicaciones que requieren de comunicaciones RFC tales como ALE, Workflow, Transport Management System, Central istration. Los s de este tipo quedan exentos del parámetro de sistema del período de validez de contraseña. Solo los es pueden cambiar la contraseña. Comunicaciones Utiliza el de tipo Comunicaciones para el logón de s no-interactivos entre sistemas. No es posible utilizar estos s para un logón de diálogo. La configuración usual del período de validez de contraseña aplica para estos s también. Servicio Un de tipo Servicio es un de diálogo que está disponible para un gran número de s anónimos. En general, estos tipos de s están muy restringidos en cuanto a autorizaciones. Los s de Servicio son usados, por ejemplo, para s anónimos al sistema utilizando ITS o servicios ICF. El sistema no verifica por la validez de la contraseña durante el logón de este tipo de s, por lo que están exentos. Solamente el de s puede cambiar la contraseña. Múltiples sesiones se permiten para estos s. Referencia Como el tipo de de Servicio, un de Referencia no está vinculado a una persona. No es posible utilizar este tipo de para loguearse al sistema. Un de Referencia es utilizado solamente para asignar autorizaciones adicionales en la solapa de Roles del registro de .

Figura 73 – Tipos de s

Transacción de istración de s SU01. Para iniciar el mantenimiento de s, transacción SU01, selecciona desde el menú Tools → istration → Maintenance → s. Es posible crear un nuevo registro maestro de copiando un registro de existente o creando completamente uno nuevo. El registro maestro de contiene toda la información y configuraciones que se requieren para poder loguearse a un cliente del sistema SAP. Estos datos están divididos en las siguientes solapas de la transacción SU01: Address: información personal y de o. Logon data: período de validez de la contraseña y del . Tipo de . Defaults: valores por defecto para una impresora, lenguaje de logón, etc. Parameters: Valores específicos de para campos estándar en el sistema SAP. Roles and Profiles: Roles y perfiles que son asignados al . Groups: Asignación de grupos para el , utilizado para el mantenimiento masivo de s. El requisito mínimo para la creación de s es ingresar al menos el apellido (Last Name) en la solapa Address, y la contraseña inicial en la solapa Logon Data.

Lección 2: Concepto de Autorización. Las autorizaciones de los s son creadas usando roles y perfiles. Los es crean los roles y el sistema provee el soporte para la creación de las autorizaciones asociadas.

Objetos de Autorización y Chequeo de Autorización Comprender el concepto de autorización de SAP requiere el conocimiento del rol y perfil de autorización en el registro maestro de un . Esta lección provee el conocimiento necesario para poder crear los roles y autorizaciones propios.

Figura 74 – Objetos de Autorización

Las acciones y los s a los datos están protegidos a través de los objetos de autorización en el sistema SAP. Los objetos de autorización se encuentran en el sistema SAP. Para facilitar un poco la organización, los objetos de autorización están divididos en diferentes clases. Los objetos de autorización permiten verificaciones complejas que involucran múltiples condiciones que permiten a un realizar una acción. Las condiciones son especificadas en los campos de autorización para el objeto de autorización y son evaluados estos campos mediante la condición lógica AND para la verificación. O sea, se deben cumplir todas las condiciones para que la verificación de autorización sea exitosa. Los objetos de autorización y los campos que contienen tienen nombres técnicos y descriptivos. En el ejemplo de la figura 74, el objeto de autorización Master Maintenance: Groups (nombre técnico: S__GRP) contiene dos campos de autorización: Actividad (nombre técnico: ACTVT) y Group in Master Record (nombre técnico: CLASS). El objeto de autorización S__GRP protege el registro maestro de justamente. Un objeto de autorización puede incluir hasta diez campos de autorización. Una autorización siempre se asocia con solo un objeto de autorización y está formada por el valor para los campos del objeto de autorización. Una autorización es un permiso para realizar cierta acción en el sistema SAP. La acción es definida sobre la base de los valores para cada uno de los campos de un objeto de autorización. Por ejemplo, la autorización B en la figura para el objeto de autorización S__GRP permite mostrar todos los registros de s que NO están asignados al grupo SUPER. La autorización A, en cambio, permite mostrar registros de s pertenecientes a ese grupo. Es posible que existan múltiples autorizaciones para un objeto de autorización. Algunas autorizaciones ya están incluidas en el sistema por SAP, pero la mayor parte son creadas específicamente por requerimientos de los clientes.

Figura 75 – Verificación de Autorización

Cuando un se loguea a un cliente de un sistema SAP, sus autorizaciones son cargadas en el contexto de . El contexto de se encuentra en el buffer (en la memoria principal, puedes consultarla mediante la transacción SU56) del servidor de aplicación. Cuando el llama a la transacción, el sistema autorización necesaria en el contexto de para verificaciones de autorización utilizan las autorizaciones . Si se asignan nuevas autorizaciones al , volverse a loguear al sistema SAP para autorizaciones.

verifica si el tiene la acceder a la transacción. Las que existen en el contexto de podría ser necesario para este poder utilizar estas nuevas

Si la verificación de autorización para llamar a la transacción es exitosa, el sistema luego muestra la pantalla inicial de la transacción. Dependiendo de la transacción, el puede crear datos o seleccionar acciones. Cuando el realiza la acción, los datos son enviados al dispatcher, el cual los pasa a un work process para que ejecute el procesamiento. Verificaciones de autorización (AUTHORITY-CHECK) que son realizadas durante la ejecución en el work process son programadas dentro del código por los desarrolladores ABAP para proteger los datos y las acciones que van a realizarse. Si el contexto de contiene todas las autorizaciones requeridas para la verificación (código de retorno = 0), los datos y las acciones son procesadas y la próxima pantalla es devuelta al . Si falta alguna de las autorizaciones requeridas, el procesamiento no se realiza y el recibe un mensaje que indica que las autorizaciones son insuficientes. Esto se controla mediante la evaluación del código de retorno. En este caso, no sería igual a 0. Todas las autorizaciones son permisos. No hay autorizaciones para prohibir. Todo aquello que no está explícitamente permitido está prohibido. Esto es lo que se conoce como concepto de autorización positivo. Mantenimiento de Roles: Menú y Autorizaciones

Figura 76 – Mantenimiento de Roles

El Mantenimiento de Roles (transacción PFCG, previamente también llamada Profile Generator o Activades de Grupo) simplifica la creación de autorizaciones y sus respectivas asignaciones a los s. En el mantenimiento de roles, las transacciones, que desde el punto de vista de la compañía, pertenecen a un mismo grupo se seleccionan. El mantenimiento de roles crea las autorizaciones con los valores de campos requeridos para los objetos de autorización que son verificados en la transacción elegida. Un rol puede ser asignado a varios s. Los cambios a un rol por lo tanto tienen efecto sobre todos estos s. Los s pueden ser asignados a más de un rol. El menú de se compone del menú de rol y contiene las entradas (transacciones, URLs, reportes, etc) que son asignadas al a través de los roles.

Figura 77 – Menú de

Puedes acceder al mantenimiento de roles con la transacción PFCG o mediante el menú de la pantalla inicial del sistema en Tools → istration → Maintenance → Role istration → Roles. Ingresa el nombre del rol y presiona el botón Create o Change. Selecciona la solapa Menu. Selecciona y modifica las funciones: En el árbol de menú se pueden realizar ajustes para los roles individuales. Se pueden insertar o borrar transacciones en el árbol de transacciones. Si se selecciona el botón Report, puedes integrar reportes (programas ABAP). En este caso la transacción PFCG se encarga de crear los códigos de transacción (si es que no existen para el reporte) con el cual los reportes luego pueden ser accedidos. Si seleccionamos el botón Other, es posible agregar direcciones de internet o vínculos a archivos. Modificación de Menús: podemos crear, mover, borrar y renombrar directorios y subdirectorios si es necesario. La función Drag&Drop se puede utilizar también.

Figura 78 – Generando Perfiles de Autorización

El mantenimiento de roles automáticamente crea las autorizaciones que están asociadas con las transacciones especificadas en el árbol del menú. De todas maneras, todos los valores de autorización deben ser verificados manualmente y ajustados si fuese necesario para que concuerden con los requerimientos y permisos que se deben otorgar con el rol. El del sistema es responsable para esta tarea, junto con el área apropiada para quien se están creando o modificando los roles. Selecciona la solapa Authorizations y luego el botón Change Authorization Data o Display Authorization Data, dependiendo en cual modo estemos trabajando en la transacción PFCG. En la pantalla que ingresamos podremos ver y modificar el contenido de las autorizaciones, o sea los valores propuestos para los campos de los objetos de autorización. El significado de los indicadores es el siguiente: Luz verde: el objeto de autorización tiene un valor propuesto para cada uno de los campos. Luz amarilla: el objeto de autorización necesita mantenimiento manual al menos para uno de los campos. Luz roja: Los niveles organizacionales no están definidos.

Figura 78_b – Significado de los indicadores

La falta de un valor propuesto por PFCG para alguno de los campos del objeto de autorización puede ser por ejemplo en los casos de s a archivos externos donde no se puede determinar si el será de lectura o de lectura/escritura. Algunos campos aparecen en muchas autorizaciones por lo que estos campos se denominan Niveles Organizacionales. Si editamos una entrada en el nivel organizacional utilizando el botón todos los objetos de autorización que lo contienen.

entonces los cambios afectarán a

¿Qué son los Niveles Organizacionales? Son campos determinados por SAP en el Concepto de Autorización que se refieren a la estructura de la compañía. Estos campos aparecen en la mayoría de las autorizaciones. Por lo tanto dentro de un rol estos campos pueden aparecer muchas veces. El botón Organizational levels… en la transacción PFCG facilita su mantenimiento.

Una vez que todas las autorizaciones han sido mantenidas como se requiere, el perfil de autorización puede ser generado mediante el botón Generate . Las autorizaciones se combinan en un perfil. Los perfiles deben ingresarse en los registros maestros de s, esto se denomina Comparación de Registros Maestros de s ( Master Record Comparission) s y Roles La asignación de s a roles se realiza mediante la transacción PFCG (mantenimiento de roles) o en la transacción de mantenimiento de SU01. Selecciona la solapa y los ID de s a los que se les asignará el rol.

Figura 79 – Asignación de Roles a s

Los s pueden recibir más de un rol, esto es útil para algunas actividades (como impresión) que serán permitidas para la mayoría de los s. La asignación de roles a los s no otorga automáticamente las correspondientes autorizaciones a los s. Para asignar las autorizaciones, es necesario realizar una comparación de registros de s mediante la cual los perfiles de los roles son insertados en el registro maestro de .

Figura 80 – Comparación de Registro Maestro de

Una comparación de registros maestros de s determina si los perfiles de autorización deben ser agregados o eliminados del basándose en la asignación de roles para este. Durante una comparación se agregarán perfiles al maestro de si nuevos roles son agregados. Si la asignación de roles es removida manualmente o porque se cumple la fecha de vencimiento del rol para el los perfiles correspondientes son eliminados del registro maestro de . La comparación puede realizarse por cada rol individualmente. Seleccionando el rol en la función de mantenimiento de roles en la solapa y luego seleccionando comparison. En la ventana que aparece, seleccionamos Complete comparison.

Para más información, selecciona el botón de información en la transacción PFCG y el mismo botón en la comparación de maestros de s. Durante una comparación completa, los perfiles obsoletos son eliminados. Si múltiples asignaciones de roles va a ser actualizada, puedes realizar una comparación en la transacción PFCG seleccionando Utilities → Mass comparison o llamando a la transacción PFUD. Puedes seleccionar los roles que desees o actualizar todas las asignaciones si ingresas el caracter asterisco (*). También puedes activar una comparación de registros maestros de s periódicamente si seleccionas Utilities → Mass comparison. Selecciona la opción Schedule o Check job for full reconciliation. El sistema luego muestra una ventana de búsqueda para el job de background PFCG_TIME_DEPENDENCY. Si no encuentra el job, tenemos la opción de crear uno. El valor por defecto es que todos los registros maestros de s serán comparados una vez por día.

Lección 3: Asignación de Roles y perfiles

Lección 4: Parámetros de e información de . En esta lección veremos una serie de parámetros importantes para la istración de s, por ejemplo, el comportamiento de logon. Parámetros del Sistema para Logon de s

Figura 81 – Parámetros del Sistema para Logon de s 1/2

Podemos especificar la longitud mínima de la contraseña con el parámetro /min__lng. El parámetro /min__digits, /min__letters, /min__lowercase, /min__uppercase, y /min__specials especifican el número de dígitos, letras (mayúsculas y minúsculas) o caracteres especiales que una contraseña puede contener. El rango de valores es entre 1 y 40. El parámetro /_expiration_time especifica el número de días en los cuales un debe cambiar su contraseña. Si el parámetro se configura en 0, el no necesita cambiar su contraseña. Existen algunas reglas generales sobre las contraseñas que no pueden desactivarse. Una contraseña: Debe ser al menos de 6 caracteres de largo. No puede comenzar con ? o ! No puede ser La nueva contraseña debe diferir de la anterior al menos en 1 carácter. La configuración que determina que los s deben crear una nueva contraseña que difiera de las 5 últimas no es más mandataria. Se puede utilizar el parámetro /_history_size para configurar el historial entre 1 y 100. El valor propuesto por defecto se mantiene en 5.

Se pueden definir restricciones adicionales en la tabla USR40. SAP Web Application Server 6.20 y 6.40 ofrecían los parámetros /_max_new_valid y /_max_reset_valid. Estos parámetros especificaban por cuanto tiempo una contraseña inicial para un creado o una contraseña recreada por el del sistema para un era válida. Con SAP Netweaver AS 7.0, estos parámetros han sido reemplazados por /_max_idle_initial. El parámetro /_max_idle_initial indica por cuánto tiempo una contraseña nueva (seleccionada por un ) permanece válida si no es utilizada. Una vez que el período se cumple, la contraseña no puede ser utilizada para la autenticación en el sistema. El de s puede reactivar la contraseña asignando nuevamente una contraseña inicial. Otro nuevo parámetro introducido luego de la versión SAP Web AS 6.40 es /_max_idle_productive. Este indica el máximo tiempo que una contraseña productiva (contraseña seleccionada por el ) permanece válida cuando esta no es usada. Una vez que este período ha caducado, la contraseña no puede ser utilizada para autenticación. El de s puede reactivar la contraseña mediante la asignación de una nueva contraseña inicial. Con el parámetro /min__diff, el puede determinar el número de caracteres diferentes que una contraseña nueva debe poseer en comparación con la contraseña anterior. Este parámetro no tiene efecto cuando la contraseña del es creada o reactivada.

Figura 82 – Parámetros del Sistema para Logon de s 2/2

Figura 83 – RZ11: Parámetros de Logon

Puedes configurar el número de intentos fallidos de logon después de los cuales SAP GUI se cierra usando el parámetro /fails_to_session_end. Si el quiere intentar de nuevo, deberá reiniciar SAP GUI. Puedes también configurar el número de intentos fallidos de logon después de los cuales el se bloquea en el sistema SAP usando el parámetro /fails_to__lock. El contador de intentos fallidos se reinicia después de un intento exitoso de logon. A la medianoche de la hora del servidor, los s que se bloquearon como resultado de intentos incorrectos de logon no son desbloqueados automáticamente por el sistema, valor por defecto desde la versión SAP Netweaver 7.0. Se puede reactivar este desbloqueo automático con el parámetro /failed__auto_unlock = 1. El puede desbloquear, bloquear o asignar una nueva contraseña a los s en la transacción SU01, mantenimiento de s. Si el parámetro /disable_multi_gui_ se configura con el valor 1, un no puede ingresar a un cliente más de una vez, o sea con más de una sesión. Esto puede ser útil por razones de seguridad del sistema. Si el parámetro está configurado en 1, el tendrá las siguientes opciones cuando abre más de una sesión: Continuar con este logon y finalizar cualquier otro logon en el sistema. Terminar este logon. Tenemos la opción de excluir de este parámetro a los s que especifiquemos en el parámetro /multi__s separados por comas y sin espacios.

s estándar

Figura 84 – s estándar

Esencialmente, hay dos tipos de s estándar: aquellos creados por la instalación del sistema SAP y aquellos creados durante la copia de un cliente. Durante la instalación del sistema SAP, el cliente 000 y 066 son creados (el cliente 001 no siempre es creado durante la instalación. Es creado por ejemplo durante la instalación de un sistema ERP 6.0). s estándar son predefinidos en los clientes. Como estos nombres de s y sus contraseñas son estándar, pueden ser conocidos por otras personas por lo tanto es aconsejable que como es del sistema protejamos estos s de s no autorizados. El estándar del sistema SAP* SAP* es el único para el cual no se requiere un registro maestro de (no existe una entrada en las tablas de s) ya que está definido en el kernel del sistema. SAP* tiene por defecto la contraseña y autorización de irrestricto para el sistema. Cuando instalamos un sistema SAP, un registro maestro de se crea automáticamente para SAP* en el cliente 000 (y 001 si existe). Durante el proceso de instalación se nos solicitará indicar una contraseña. La instalación solo nos permitirá continuar una vez que una contraseña se ha ingresado para el SAP*. El registro maestro de creado para el SAP* desactiva las propiedades especiales de SAP*, por lo que solo las autorizaciones y contraseñas definidas en el registro maestro del aplican ahora.

El DDIC Este es responsable de mantener el Diccionario ABAP (ABAP Dictionary) y la logística de software. Cuando instalamos el sistema, un registro maestro de automáticamente en el cliente 000 (y 001 si aplica) para el DDIC.

se

crea

Con este también, se nos requerirá cambiar la contraseña estándar durante la instalación. Ciertas autorizaciones son predefinidas en el código del sistema para el DDIC, lo que significa que por ejemplo, solo el DDIC puede realizar un logon al sistema durante la instalación de una nueva versión (upgrade). En versiones anteriores las contraseñas que tenían por defecto los s SAP* y DDIC eran 06071992 y 19920706 respectivamente. Luego era necesario modificar estas contraseñas una vez instalado el sistema.

El EarlyWatch El EarlyWatch se crea en el cliente 066 y está protegido con la contraseña . Los expertos de SAP del servicio EarlyWatch son quienes utilizan este . Este no debe ser borrado ni la contraseña debe ser cambiada. Este solo debe ser utilizado para las funciones de EarlyWatch: monitoreo y peformance. Las autorizaciones necesarias para este ya son provistas durante la creación del mismo en el proceso de instalación. Caracteristicas especiales de SAP* Si copias un cliente, el SAP* siempre está disponible. Este no tiene un registro maestro de y está programado en código del sistema (kernel). Para proteger el sistema contra s no autorizados, debemos crear un registro de para este estándar. Crea un SAP* con autorizaciones totales en el sistema (perfil SAP_ALL).

Si borramos el registro de SAP* (tabla USR02), la contraseña inicial con las propiedades vuelven a ser válidas nuevamente: el tiene autorizaciones totales ya que no se realizan verificaciones de autorización para este . La contraseña estándar no puede ser cambiada. ¿De qué manera podemos proteger el sistema contra este potencial riesgo de no autorizado? Se puede desactivar el SAP* que viene incluido en el sistema. Para esto, debemos configurar el parámetro del sistema /no_automatic__sapstar con el valor 1. Si el parámetro está activo, o sea con el valor 1, SAP* no es válido en el sistema. Si el registro maestro de de SAP* es borrado, el logon con la contraseña no funciona.

Si quisiéramos reinstalar el comportamiento anterior de SAP*, debemos cambiar el parámetro con el valor 0 y reiniciar el sistema. Es conveniente activar el parámetro en el perfil global del sistema DEFAULT.PFL para que tenga efecto en todas las instancias del sistema (de todas formas si existiera el parámetro también en un perfil de instancia con el valor 0, este sobrescribe el que está en el perfil global). También crear el registro maestro de SAP* en todas las instancias y así asegurar que no se podrá ingresar con el si el parámetro es desactivado (valor 0).

Lección 5: Concepto istración Avanzada de s istración Central de s

Figura 85 – istración Central de s

Cuando tenemos que operar múltiples sistemas SAP con una determinada cantidad de clientes y tenemos que crear s idénticos varias veces en diferentes clientes, podemos reducir significativamente el esfuerzo de istración usando istración Central de s, que por las siglas en inglés se conoce como CUA (Central istration). Podremos realizar la istración de forma central desde un cliente si utilizamos CUA. Este cliente se denomina Sistema Central (Central System). Los clientes para los cuales se realiza la istración desde el sistema central se denominan Sistemas Hijos (Child Systems). Puedes especificar para cada en que clientes podrá ingresar. Utilizando CUA no significa que todos los s pueden ser usados en todos los clientes del landscape. Puedes también especificar que información del registro maestro de podrá ser mantenida de forma central y que información se podrá mantener de forma local

también. Algunas veces es útil permitir que cierta información de s sea mantenida de forma local por los s o por un en los sistemas hijos. La información del se intercambia mediante ALE. ALE significa Application Link Enabling y es una tecnología para configurar y operar aplicaciones SAP distribuidas. ALE permite un proceso de intercambio controlado de mensajes de negocio entre sistemas SAP que no tienen una conexión permanente. El procesamiento asincrónico de la comunicación asegura que la operación sea libre de errores.

Figura 86 - ¿Qué Información Puede Ser Distribuida?

La siguiente información puede ser distribuida utilizando CUA: Registro Maestro de s: Dirección, Datos Logon, Valores Fijos, Parámetros (addresses, logon data, defaults y parameters) Los s son asignados a los roles simples o compuestos y los perfiles para todos los sistemas hijos. Utilizar CUA tiene la ventaja que como es no necesitamos ingresar a cada cliente para gestionar estas asignaciones localmente. Contraseña inicial: Cuando los s son creados una contraseña inicial es transferida a los sistemas hijos donde el existirá. Esta luego será modificada de la forma tradicional. Bloqueo: adicionalmente a las formas normales de bloqueo (intentos fallidos de logon o bloqueos por el ) hay un nuevo bloqueo general. Este tiene efecto en todos los sistemas hijos en los que un existe y puede quitarse el bloqueo de forma local en cada cliente o de forma central desde el sistema central. Es posible asignar un rol simple o compuesto y perfiles de autorización desde el sistema central. De todas formas, los perfiles de autorización se mantienen localmente más bien que de forma central ya que diferentes configuraciones de sistema y versiones pueden requerir una istración local de los perfiles de autorización.

Comunicación y Logística de Software Lección 1: Fundamentos de Conexiones RFC Los sistemas SAP pueden comunicarse entre sí utilizando Llamadas de Funciones Remotas, que por sus siglas en inglés se conocen como RFCs (Remote Function Calls). Un prerrequisito para esto es que el haya configurado el sistema de interfaces. Fundamentos de RFC Las Llamadas de Funciones Remotas han sido utilizadas por muchos años como la interfaz técnica con la que los sistemas SAP y no-SAP usualmente se conectan. No tiene relevancia si el intercambio de información se realiza de manera sincrónica o asincrónica, periódica o aperiódica, o transaccional.

Figura 87– La interfaz RFC

Una RFC es la llamada a un módulo de función que está corriendo en un sistema diferente al programa que realiza la llamada. Podemos llamar a un módulo de función en el mismo sistema mediante una RFC también. De todas maneras, las RFCs normalmente son utilizadas cuando los módulos de funciones, el que llama y el que recibe el llamado, se encuentran en sistemas diferentes. En el sistema SAP, el sistema de interfaz RFC provee esta función. El sistema de interfaz RFC permite llamadas a funciones entre dos sistemas SAP o entre un sistema SAP y un sistema no-SAP externo. RFC es un protocolo de interfaz de SAP basado en la intefaz de Programación Común Para Comunicaciones, por sus siglas en inglés I-C (Common Programming Interface for Communication) y permite comunicación entre programas de diferentes hosts. Esto permite que las aplicaciones externas puedan llamar funciones ABAP y los sistemas SAP ar aplicaciones externas que sean compatibles mediante RFC.

RFC significa que los programadores ABAP no tienen que escribir sus propias rutinas de comunicación. Para una llamada RFC, la interfaz RFC: Convierte todos los parámetros al formato requerido en el sistema remoto. Invoca a las rutinas de comunicación que se requieren para la comunicación con el sistema remoto Maneja los errores que pueden ocurrir durante la comunicación. La interfaz RFC es de fácil utilización para los programadores ABAP. Los pasos de procesamiento para el llamado a los programas externos están integrados dentro de la sentencia CALL FUNCTION.

Figura 88 – Conexiones RFC

Para poder llamar a una función remota (en un sistema remoto), deberemos definir el sistema remoto como un destino en el sistema desde donde realizamos la llamada. También se requiere autorización de para el sistema remoto. Se pueden manejar estas conexiones remotas en el sistema que llama. Para hacer esto, utilizamos la función Display and Maintain RFC Destinations, ya sea seleccionando desde el árbol del menú del sistema la ruta istration → istration → Network → RFC Destinations o directamente llamando a la transacción SM59. Los tipos de conexión y todos los destinos existentes se muestran en una estructura de árbol en la pantalla inicial. Para detalles sobre los tipos de conexión disponibles, podemos observar la documentación. Hay una función de búsqueda para los destinos que ya están configurados. Para realizar una búsqueda, selecciona Search y luego ingresa el nombre o parte del nombre. El sistema mostrará una lista de las entradas que concuerden. Para modificar una conexión RFC existente, seleccionamos el destino RFC en el menú de árbol y seleccionamos Change Para copiar una conexión RFC existente, primero tenemos que ingresar a la conexión RFC que queremos copiar. Luego seleccionar Connection → Copy.

Variantes de Utilización de RFC RFC sincrónica (sRFC) Para comunicación entre diferentes sistemas y entre SAP Netweaver AS y SAP GUI. En estas comunicaciones el llamado a la función remota se basa en una comunicación sincrónica por lo que el sistema remoto debe estar disponible en el momento de la llamada. RFC asincrónica (aRFC) Para comunicación entre sistemas y para procesamiento paralelo de tareas. Con este tipo de comunicación, aunque no es realmente asincrónica ya que el sistema remoto debe estar disponible al momento de la comunicación, el sistema origen (desde donde se realiza la llamada a la función remota) no necesita esperar una respuesta del sistema remoto para continuar su procesamiento y en este sentido es por el cual se denomina asincrónica. RFC transaccional (tRFC) Este método si utiliza una forma de comunicación realmente asincrónica. El sistema remoto no necesariamente debe estar disponible al momento de la llamada por el programa en el sistema origen. Si una llamada es ejecutada y el sistema destino no está disponible, la llamada se mantiene en una cola local del sistema origen. El programa que ejecutó la llamada puede proceder sin esperar si el resultado de la llamada fue exitoso o no. RFC encolada (qRFC) Para garantizar que se procesen en el mismo orden en el que se realizaron las llamadas en el sistema origen, qRFC garantiza esto. Es una extensión de tRFC. Se utiliza cuando necesitamos que el procesamiento se realice con un orden predefinido (establecido por el orden de los llamados desde el programa en el sistema origen). RFC es un término general para diferentes variantes de implementación. sRFC es la llamada de módulo de funciones sincrónica. Esto significa que el cliente espera hasta que el servidor ha completado el procesamiento de la función remota. Dentro un sistema SAP, una RFC puede también ser ejecutada de forma asincrónica mediante el uso de otro work process. La variante se conoce como aRFC. También está tRFC que es la Llamada de Función Remota Transaccional, la cual es asincrónica ya que asegura que la información puede ser enviada más de una vez al sistema destino si problemas de comunicación en la red suceden y son reconocidos del lado del servidor. Para esto un identificador de Transacción (TID) se asigna al llamado. Esto es útil para prevenir que la información se procese más de una vez en el sistema lo que podría ocasionar información errónea en la aplicación debido al procesamiento asincrónico. qRFC con cola de envío es una extensión de tRFC. Crea una capa entre la aplicación y tRFC y permite enviar los parámetros de la función remota si no existen ejecuciones anteriores pendientes en la cola. Luego de que una unidad lógica de trabajo (LUW) es

ejecutada, el coordinador de qRFC automáticamente procesa el siguiente llamado en concordancia con la secuencia de la cola.

Lección 2: Configuración de Conexiones RFC Transacción SM59

Lección 3: Estructura de Sistemas SAP En esta lección veremos la estructura de datos de un sistema SAP. Téminos como cliente, customizing (adaptación) dependiente de cliente y customizing inter-cliente (cross-client), datos maestros y de transacciones, datos de y repositorio de objetos serán descriptos. Por último las opciones para modificar y crear objetos de repositorio serán parte de la lección también. El software de SAP necesita ser adaptado a los requerimientos específicos de las compañías. ¿Cómo podemos transferir esas adaptaciones desde el sistema de desarrollo al sistema de producción? El esfuerzo de trabajo extra debemos procurar que sea mínimo cuando importamos Packages o durante un posible Upgrade del sistema. Veremos cómo se relacionan estos en SAP.

Estructura de Datos en un Sistema SAP Conocer la estructura de datos de un sistema SAP es igualmente importante tanto para los s, desarrolladores y es para entender de qué manera un sistema SAP funciona.

Figura 89 – Estructura de Datos de un Sistema SAP

Los sistemas SAP tienen una estructura de datos específica. Adicionalmente a las configuraciones de negocio (customizing) que son relevante únicamente para ciertos clientes del sistema SAP, también contiene configuraciones y el repositorio de objetos que son inter-clientes (cross-client). El repositorio es el lugar de almacenamiento central para todos los objetos de desarrollo de Workbench ABAP y es inter-cliente. Los objetos de repositorio se almacenan en paquetes (packages). Los paquetes son contenedores para objetos de desarrollo relacionados semánticamente. Diferentes objetos de desarrollo (programas, tablas, pantallas, módulos de función, clases, etc) pueden estar contenidos dentro de un paquete. Los paquetes están caracterizados por ciertas propiedades: Anidado (nesting) Interfaces (interfaces) Visibilidad (visibility) Accesibilidad (accesibility) Los paquetes son creados y mantenidos con Package Builder, la transacción SPAK. El grabado y transporte de modificaciones de objetos está controlado por el Sistema de Transportes y Cambios, que por sus siglas en inglés se denomina CTS (Change and Transport System) utilizando la asignación de objetos de repositorios a paquetes.

Customizing El término Customizing, que se podría traducir como adaptaciones, describe las configuraciones de negocio de un sistema SAP. Las funciones provistas tantos generales de una compañía como aquellas que pueden ser específicas para una industria son adaptadas a los requerimientos específicos de la empresa en el proceso de Customizing. El Customizing comprende cosas simples y básicas como la definición de plantas y almacenes hasta cosas más complejas como funciones de compras basadas en planificación de producción o liquidación de nómina. Una gran cantidad de Customizing estándar tal como definiciones de país, lenguaje, uso horario están incluidas por SAP como parte de las instalaciones. El sistema SAP diferencia entre Customizing dependiente de cliente y Customizing inter-clientes. Customizing inter-clientes contiene configuraciones que son independientes de una unidad de negocio particular y tienen una validez general. Entre otros incluye el calendario, configuraciones de impresión o el a la ayuda. Clientes Los sistemas SAP están divididos entre unidades de negocio o clientes, que también se conocen como mandantes. Un cliente es una unidad comercial, organizacional y técnica contenida en un sistema SAP y consiste de configuraciones de negocio (customizing dependiente de cliente), sus propios datos maestros y transaccionales y sus propios datos de s. Los datos de un cliente se conocen como datos dependientes de cliente o específicos de cliente. Los tipos de datos que son dependientes de un cliente están relacionados entre sí. Por lo tanto, cuando ingresamos información en una aplicación, el sistema verifica si la información ingresada concuerda con la configuración específica de ese cliente (Customizing). Si hay inconsistencias, la información ingresada en la aplicación es rechazada. Esto nos dice que la información de una aplicación es significativa en términos del negocio solamente en el cliente con el Customizing correspondiente. Ejemplos de Customizing dependiente de cliente son los códigos de compañía, plantas y almacenes. Datos Maestros y de Transacciones son dependientes del cliente también. Son únicamente válidos en el cliente. Esto incluye por ejemplo registros maestros de materiales, órdenes y facturas. Los datos de también son dependientes de cliente. Varios roles de clientes son utilizados en un sistema SAP. Un cliente de Customizing puede ser configurado para las configuraciones que sean dependientes de cliente en el sistema de desarrollo. En un sistema de calidad, un cliente puede crearse para

propósitos de pruebas y en un sistema de producción, un cliente para trabajo productivo. Los roles se asignan a los clientes desde la transacción SCC4. Repositorio de Objetos

Figura 90 – Ajustes a las Estructuras de Datos

Así como el Customizing dependiente de cliente e inter-cliente, es posible realizar ajustes adicionales a la estructura de datos de un sistema SAP también. Se pueden realizar cambios o mejoras en el repositorio de objetos. Los cambios o mejoras al repositorio pueden realizarse en diferentes formas: Extensión del repositorio a través de desarrollos del cliente (customer developments): en el sistema SAP, es posible crear objetos de repositorio propios tales como tablas, programas, transacciones, etc. Todos los desarrollos del cliente son usualmente realizados en el espacio de nombres del cliente y deben comenzar con la letra Y o Z, entre otras cosas. Es posible, de todas formas, también requerir un nombre de espacio propio a SAP que empiece y termine con el caracter /. Este tendrá un máximo de ocho caracteres inlcuyendo /, tal como /Firma/. Todos los objetos que se creen bajo el nombre del espacio tendrán un nombre que empezará con /Firma/, tal como /Firma/Evaluacion1. Mejoras de cliente (customer enhancement): el repositorio es suplementado por sub-objetos del cliente aquí. Por ejemplo, un programa estándar de SAP puede ser suplementado con código propio del cliente en puntos predefinidos en el código conocidos como customer exits (salidas de cliente). Las estructuras de tablas pueden ser ampliadas con campos propios utilizando appends (agregados) Modificaciones al estándar del sistema SAP: cambios a objetos estándar de SAP (programas, tablas, estructuras) se conocen como modificaciones. El repositorio de objetos que vienen junto con el sistema SAP en este caso no es extendido sino directamente modificado.

Varios tipos de modificaciones son posibles, dependiendo del tipo de objeto: Modificaciones manuales Modificaciones con el asistente de modificaciones Modificaciones con el asistente de notas Landscape de Tres Sistemas SAP recomienda un landscape de sistemas múltiples basado en la conformación de la estructura de datos de un sistema SAP, en la que existe solo un repositorio de objetos por sistema. Nunca se debe desarrollar en un sistema SAP que se utiliza también como productivo. En circunstancias normales, un landscape de tres sistemas es suficiente para la operación.

Figura 91 – Landscape de tres sistemas

Como el repositorio de objetos es inter-cliente, SAP recomienda que no se desarrolle en un sistema que al mismo tiempo se utiliza para trabajar en forma productiva, ya que esto conlleva un riesgo de una posible inconsistencia de datos. Si se van a realizar cambios al repositorio, SAP recomienda que se utilice al menos dos, pero idealmente tres sistemas separados. Un sistema para desarrollos, un segundo sistema para pruebas y aseguramiento de la calidad y un tercer sistema productivo. Un landscape de tres sistemas facilita el siguiente proceso recomendado: Se realizan desarrollos propios de cliente en el repositorio de objetos y las configuraciones (Customizing) requeridas en el sistema de desarrollo. Las configuraciones de Customizing realizadas, así también como todos los cambios (desarrollos, mejoras y modificaciones) al repositorio se registran en el sistema de desarrollo. Estos cambios son luego transportados al sistema de calidad y se verifican allí, sin influenciar la operación de producción. Una prueba de aceptación usualmente no es posible realizarse en el sistema de desarrollo, ya que los datos reales no están disponibles en este sistema para una prueba real. La razón principal, de todas formas, es que el sistema de desarrollo no ofrece un

ambiente estable para una prueba comprensiva e integral: muchos desarrolladores trabajan en un número de diferentes proyectos al mismo tiempo. Luego de que se han probado satisfactoriamente, todos los objetos y configuraciones en el sistema de calidad pueden ser transportados al sistema de producción. Diferentes clientes pueden ser creados para propósitos específicos. Si realizamos un Customizing dependiente de cliente en el sistema de desarrollo y queremos verificarlo antes de transportarlo a los demás sistemas, puede utilizarse un cliente de prueba en el mismo sistema de desarrollo para tal propósito. Clientes con roles específicos son usualmente creados en cada sistema: un cliente de desarrollo en el sistema de desarrollo, un cliente para pruebas en el sistema de calidad y un cliente productivo en el sistema de producción. Generalmente, los clientes principales de cada sistema tienen el mismo número ya que por defecto cuando transportamos el cliente origen es igual al cliente destino. Esto último de todas formas no es obligatorio.

Lección 4: Transportes en SAP Los cambios que los desarrolladores realizan en el sistema de desarrollo deben ser transportados al sistema de calidad para realizar las pruebas necesarias y luego al sistema de producción. El transporte de cambios es una de las tareas del del sistema o de un de transportes. Órdenes de Transportes y Tareas Los transportes de Workbench y Customizing pueden ambos ser creados con el Organizador de Transportes (Transport Organizer), transacción SE09 o SE10. Como parte de una orden de transporte, el líder de proyecto es quien se encarga de definir tareas para el tipo de orden (Workbench o Customizing) y asigna cada una a un correspondiente. Después que cada tarea individualmente es liberada, la orden de transporte puede ser liberada también. Liberar la orden de transporte genera que esta sea exportada. Después de que se realiza la exportación, la orden de transporte está en condiciones de ser importada en el sistema destino. En un sistema de desarrollo, las configuraciones de Customizing son realizadas y modificadas, los objetos de repositorio son creados y los que existen son modificados. Para transportar estos objetos en los sistemas siguientes del landscape, necesitamos una orden de transporte. Sin una orden de transporte no podemos transportar configuraciones de Customizing u objetos de repositorio. Esto es porque, dependiendo de la configuración del sistema, necesitaremos asignar a una tarea, la cual está incluida en una orden de transporte, cada modificación o nuevo objeto que creemos o configuración de Customizing que realicemos. Cuando un proyecto de desarrollo comienza, el líder del proyecto idealmente deberá crear una o más órdenes de transporte. Durante el proceso las personas involucradas en el proyecto son asignadas a tareas dentro de esas órdenes de transporte.

Una orden de transporte por lo tanto pertenece al líder del proyecto y generalmente comprende varias tareas, cada una de ellas asignada a una persona para el proyecto.

Figura 92 – Estructura de Órdenes de Transporte

El Organizador de Transportes Uno de los lugares donde podemos crear una orden de transporte es en el Organizador de Transportes, transacción SE09.

Figura 93 - El Organizador de Transportes

El Organizador de Transportes genera un nombre para la orden de transporte creada. Este nombre se compone del SID del sistema de desarrollo, o mejor dicho, del sistema donde estamos creando la orden. Luego, los caracteres K9 y cinco dígitos que combinados forman una secuencia alfanumérica. Por ejemplo DEVK901234. Una orden de transporte debería contener objetos que están lógicamente relacionados y serán transportados juntos. Esto es, una orden de transporte nos permite transportar y istrar desarrollos completos, lógicos y auto-contenidos. Una nueva orden de

transportes no es requerida para cada objeto, ya que esto resultaría en una gran cantidad de órdenes de transportes y la istración se volvería compleja y confusa lo que también llevaría a errores con los transportes potencialmente. El Organizador de Transportes crea una tarea para cada persona involucrada en la orden de transporte. Si una persona asigna un objeto a la orden de transporte, el objeto se registra en la tarea de esa persona. De esta manera, todos los objetos que una persona edita o crea durante el proyecto de desarrollo son registrados en la tarea. La convención de nombres para las tareas es la misma que para las órdenes de transporte. Una orden de transporte se diferencia entre varios términos. El término orden de transporte es el término general o neutral. Una orden de modificación o cambio es una orden de transporte utilizada para transportar cambios. Los objetos que contiene, pueden por supuesto, ser transportados sin que ningún cambio se haya realizado sobre ellos, tal es el caso de objetos nuevos creados en el repositorio. Una orden de Workbench es una orden de transportes en la que objetos de repositorio o Customizing inter-cliente son transportados. Una orden de Customizing es una orden de transporte en la que objetos dependientes de cliente son transportados, en otras palabras, Customizing dependiente de cliente, datos maestros, transaccionales o datos de . De los tres, normalmente solamente Customizing dependiente de cliente es transportado. Una orden de consolidación es una orden de transporte que será transportada al sistema de consolidación (sistema de calidad). Transportes El transporte de objetos está dividido en las fases de Exportación e Importación: los objetos son exportados desde el sistema de desarrollo e importados en los sistemas destino tales como el sistema de calidad y el sistema de producción.

Figura 94 – Transportes en un Landscape de Tres Sistemas

La liberación de una orden de transporte dispara la exportación de los objetos que se encuentran registrados por nombre en la orden de transporte. Estos objetos se almacenan ahora en archivos de datos (data files) en el directorio de transportes central. La información respecto del éxito de la liberación y la exportación queda guardada en el log (registro) de transporte de la orden de transporte.

La importación en el sistema destino es usualmente no automática, pero es iniciada por el de transportes en el Sistema de Gestión de Transportes, que por sus siglas en inglés se conoce como TMS (Transport Management System) y podemos acceder mediante la transacción STMS. Los registros de importación también son guardados en el log de transporte.

Figura 95 – Log de Transporte

En términos técnicos, una copia de los datos desde la base de datos del sistema de desarrollo se escribe al directorio de transportes central durante la exportación de la orden de transporte. Durante la importación, la orden de transporte almacenada en el directorio central de transporte se copia a la base de datos del sistema destino. El directorio central de transporte está físicamente ubicado en un sistema de archivos (file system) al cual todos los sistemas que pertenecen al landscape de SAP tienen de lectura y escritura. Cada sistema encuentra la ubicación del directorio de transportes que utilizará, ya sea para escribir o leer las órdenes de transporte, por medio del parámetro de perfil DIR_TRANS. La ubicación por defecto del directorio de transportes es: /usr/sap/trans De todas maneras, esto puede ser adaptado según los requerimientos. Solo en casos excepcionales puede ser necesario utilizar varios directorios de transporte locales en vez de un directorio central. Esto hace que el proceso de transportes sea un poco más complejo, pero podría ser útil en algunos casos por razones de seguridad de la red.

Importación El de transportes usualmente inicia la importación en los sistemas subsiguientes manualmente usando el TMS (Transport Management System) en el sistema SAP correspondiente, con la transacción STMS. En los sistemas posteriores a desarrollo, podemos ver que ordenes de transportes están encoladas para ser importadas dentro del sistema en la transacción STMS. Desde un punto de vista técnico en un landscape de tres sistemas, la orden de transporte es marcada para importación en el sistema siguiente (sistema de calidad) cuando es exportada desde el sistema de desarrollo. Es posible ver esta marca de la orden de transporte para importación en el siguiente sistema en el TMS, transacción STMS por medio de la opción de menú Overview → Imports.

Figura 96 – STMS – Colas de Importación

Esto muestra la cola de importación para el sistema. Para ver los detalles sobre la cola de importación, selecciona Import Queue → Display

Figura 97 – Visualización de Cola de Importación

Existe un número de métodos disponibles en la cola de importación de TMS para importar las órdenes de transporte en el sistema destino. Los métodos más importantes son Import All Transport Requests (Importación Masiva de Ordenes de Transporte) e Import Individual Transport Requests (Importación Individual de Ordenes de Transporte). Es posible ejecutar estos métodos en diálogo o en background.

Figura 98 – Métodos de Importación

Cuando importamos ordenes individuales, tenemos que seleccionar la orden de la cola de importación y luego importarla con la opción indicada. Cuando importamos ordenes de transporte de manera masiva, todas las ordenes en la cola de importación son importadas. En ambos casos, los objetos son importados primero en orden de importancia y segundo en el orden que tiene la orden de transporte en la cola de importación. Una tabla por lo tanto es más importante que un programa porque el programa puede ser dependiente de la tabla. El orden de las órdenes de transporte en la cola de importación del sistema de calidad asegura que sea el mismo orden en el que se exportaron desde el sistema de desarrollo. Por comparación, el orden en la cola de importación del sistema de producción se define por el orden con el que se importó en el sistema de calidad. La cola de importación del sistema de producción puede ser por lo tanto organizada de manera diferente a la del sistema de calidad. Esto es correcto, ya que esto refleja el orden de la importación al sistema de calidad y por lo tanto la aceptación técnica en el sistema de calidad. En el sistema SAP, el de transportes inicia la importación utilizando la transacción STMS, eligiendo la cola de importación con la opción de menú Overview → Imports, seleccionando el sistema en el cual la importación se llevará a cabo y eligiendo Import Queue → Display. La importación inicia ya sea con el botón Import All Requests

o Import Request

Técnicamente, el programa tp del sistema operativo es utilizado para la exportación y la importación. La importación siempre usa los archivos de datos que fueron generados y almacenados en el directorio central de transportes durante la exportación.

Lección 5: Órdenes de Customizing Órdenes de Customizing Una orden de Customizing puede contener objetos de Customizing dependientes de cliente, datos maestros, datos transaccionales y de s. Normalmente, solamente Customizing dependiente de cliente es transportado en una orden de Customizing. En el caso que sea necesario transportar Customizing inter-cliente deberá ser incluido en una orden de tipo Workbench. El Organizador de Transporte crea una tarea para cada persona en la orden de transporte. Si una persona asigna un objeto de Customizing a la orden de Customizing, el objetos es registrado por nombre en la tarea de esa persona. De esta manera, todos los objetos de Customizing editados por esa persona se registran en la tarea. Cuando las personas han completado el Customizing, liberan sus respectivas tareas. Esto transfiere los objetos registrados en las tareas a la orden de Customizing. Una vez que todas las personas han liberado sus tareas, el líder de projecto puede liberar la orden de Customizing y por lo tanto realizar la exportación.

Figura 99– Ejecución, Liberación y Transporte de Customizing

La estructura de los proyectos de Customizing es similar a la estructura de proyectos de desarrollo. Las personas involucradas en este caso son el líder de proyecto de Customizing, quien crea y libera las ordenes de Customizing, y los del proyecto, quienes realizan el Customizing y asignan las configuraciones realizadas a la orden de Customizing mediante las tareas. Los cambios a los datos de Customizing se registran en el Organizador de Transportes y en consecuencia en las tareas de las ordenes de Customizing, aunque en el caso de Customizing, las entradas de tabla que son modificadas son solamente bloqueadas

durante el tiempo que se está trabajando en la modificación y es realizado por el enqueue work process. Para resumir, podemos decir que las configuraciones que son dependientes de cliente, son modificaciones que se realizan en tablas del sistema, las cuales tienen un campo clave que determina el número de cliente donde estamos trabajando.

Figura 100 – Estructura de una tabla de Customizing

Solamente durante el tiempo que estamos realizando los cambios los registros de dichas tablas estarán bloqueadas con el sistema de bloqueo del sistema SAP. Una vez que guardamos los cambios y quedan registrados en la tarea de Customizing, el bloqueo se libera.

Figura 101 – Vista de una Orden de Customizing en el Organizador de Transporte

Lección 6: Órdenes de Workbench Órdenes de Workbench Las órdenes de Workbench son órdenes de transporte de Customizing inter-cliente y objetos de repositorio. El proceso ilustrado aquí es utilizando objetos de repositorio como ejemplo. El proceso para el Customizing inter-cliente es el mismo que para las órdenes de Customizing. El Organizador de Transportes crea una tarea para cada persona en la orden de transporte. Si una persona asigna un objeto de repositorio a la orden de transportes, el objeto de repositorio es registrado por el nombre en la tarea de esa persona. Cuando el proyecto de desarrollo está completo desde el punto de vista del miembro del proyecto, él o ella libera su tarea. Esto transfiere el objeto en la tarea a la orden de transporte. Una vez que todas las personas han liberado sus tareas, el líder del proyecto de desarrollo puede liberar la orden de transporte y, en consecuencia, se genera la exportación de la orden de transporte. Una orden de Workbench, por lo tanto, agrupa objetos de repositorio con los que se han trabajado durante un proyecto de desarrollo.

Figura 102 – Desarrollo, Liberación y Transporte de Objetos de Respositorio

Si un objeto de repositorio es editado e incluido en una orden de transporte por un desarrollador, este objeto se encuentra reservado exclusivamente para ser procesado en esta orden de transporte. Cambios a este objeto pueden ser realizados por los desarrolladores que también tengan tareas en la orden de transporte. El desarrollo o mantenimiento de los objetos está bloqueado para todos los otros desarrolladores que no están involucrados en la misma orden de transporte hasta que la misma es liberada. Estos desarrolladores solo podrán visualizar los objetos.

Figura 103 – Ejemplo de Objeto de Repositorio en el Editor ABAP

Cada persona que está involucrada en la orden de transporte y edita el objeto recibe una entrada correspondiente en la lista de objetos de su tarea. De esta manera, es posible determinar quien o quienes editaron un objeto.

Figura 104 - Visualización de una orden de Workbench en el Organizador de Transportes

Los objetos son desbloqueados cuando la orden de transporte es liberada. Otros desarrolladores pueden luego trabajar sobre el objeto nuevamente. En los cambios a los datos de Customizing, también son registrados por el Organizador de Transportes, pero las tablas solo están bloqueadas durante el proceso de modificación por el enqueue work process. No hay bloqueo de objetos para Customizing.

El Organizador de Transportes también lleva el versionado de los objetos de repositorio, permitiendo comparaciones y también el a versiones anteriores. De esta manera, es posible documentar y recrear si es necesario, los diferentes estados, posteriores y anteriores, a una orden de transporte o un proyecto de desarrollo. Una versión es generada cuando la orden de transporte es liberada.

Mantenimiento del software SAP Lección 1: Notas y Packages Luego de que finalizamos la instalación de un sistema SAP, es muy probable que necesitemos importar ajustes que se realizaron debido a cambios en requerimientos legales, y corregir errores que podría haber en el software del sistema SAP. SAP provee las notas de SAP y los Packages para este propósito. Notas SAP y Packages Un sistema SAP se conforma de varios componentes de software. Estos componentes se actualizan regularmente a través de Notas de SAP y Packages . Ambos son utilizados para importar al sistema cambios en requerimientos legales, corregir errores y en algunos casos mejorar ciertas funciones existentes o incorporar nuevas funciones. El sistema SAP debería siempre tener el nivel de actualización más reciente, por un lado para cumplir con los requerimientos legales que puedan existir en el lugar donde opera y para eliminar los errores que existen en el estándar por otro.

Figura 105 – Notas SAP y Packages

Las Notas de SAP pueden contener información general, recomendaciones o indicaciones de SAP. También pueden describir un problema y su resolución al error en funciones estándar del software SAP. Este último tipo de Notas SAP contiene una solución a un problema individual, el cual es generalmente una corrección a un error de programación, que obtenemos en la forma de líneas de código fuente con las modificaciones necesarias para solucionar el error. Las notas de SAP son muy utilizadas por los es de sistema para resolver problemas específicos como errores en tiempo de ejecución de programas estándar o fallas en los componentes del kernel por ejemplo. La base de notas de SAP puede accederse a través del enlace rápido http://service.sap.com/notes. La base de Notas de SAP se encuentra dentro del Marketplace de SAP (http://service.sap.com) pero necesitamos de un especial para poder ingresar llamado S. Cada cliente de SAP es provisto por un super S el cual luego puede crear s S adicionales con diferentes permisos dentro de Marketplace. Los Packages son un conjunto de objetos de repositorio. En principio, cada componente de software para cada nivel de versión tiene sus propios Packages. En el caso de componentes de software que intersectan (con add-ons modificados, por ejemplo), existe un tipo de Package adicional llamado Transporte de Resolución de Conflictos, que por sus siglas en inglés se conoce como CRT (Conflict Resolution Transport) Los add-ons se implementan para soluciones de industria específica y modifican un componente de software estándar (tal como por ejemplo SAP_APPL). Técnicamente hablando, los Packages son un tipo de orden transporte que no puede ser importada por los métodos normales que vimos en la unidad anterior. Un Package contiene todas las Notas de SAP relevante a ese componente de software y versión que se crearon desde el Package anterior al mismo. Los Packages son por lo tanto no acumulativos y requieren siempre del anterior para poder ser implementado. Los Packages son implementados en el sistema con el Package Manager, transacción SPAM. Las Notas de SAP son implementadas con el Asistente de Notas, transacción SNOTE.

Transacción SNOTE El Asistente de Notas se accede a través de la transacción SNOTE. Desde el SNOTE podemos implementar varios tipos de notas: cambios a programas SAP, creación de nuevos programas SAP, cambios a módulos de función SAP y varias otras cosas. De todas formas, el Asistente de Notas no puede modificar objetos de Diccionario por ejemplo. Además, el Asistente de Notas puede sólo modificar objetos de repositorio y no Customizing.

Figura 106 – Asistente de Notas: proceso de implementación

Siguiendo la Figura 106, Las Notas de SAP se implementan con el Asistente de Notas en los siguientes pasos: 1. Primero debemos localizar la Nota de SAP requerida en el SAP Marketplace, por ejemplo, buscando por palabras claves o utilizando el número de nota si es que ya conocemos cual es la que necesitamos. 2. Luego podemos cargar la Nota de SAP al sistema de desarrollo mediante el Asistente de Notas (SNOTE) 3. La Nota de SAP es verificada por el Asistente de Notas. Verifica si el nivel de versión del componente de software donde se va aplicar y el nivel de actualización de Package del mismo son correctos para los prerrequisitos de la nota. También verifica si la nota requiere de otras notas previamente implementadas y si puede ser implementada cuando existen otras modificaciones sobre los objetos que están afectados por la misma. 4. La Nota de SAP es implementada mediante la función de importación. Esto crea una orden de transporte. 5. El resultado de la implementación de la Nota de SAP se prueba en forma general en el sistema de desarrollo. Si la Nota no corrige el problema puede desimplementarse también mediante la transacción SNOTE. 6. Si el resultado de la prueba es exitoso, por ejemplo si el error ya no se produce luego de implementar la nota en el programa que corrigió, la orden de transporte se libera y se importa en el sistema de calidad mediante el sistema de transportes. La aceptación técnica se realiza en este sistema. 7. Si también resulta correcta la aceptación, entonces la orden de transporte es importada en el sistema de producción.

Packages Stacks En principio, la importación de Packages para un componente de software en particular es independiente de los Packages de otros componentes de software. Los componentes individualmente son en general independientes de otro u otros componentes de software. De todas maneras, pueden existir casos donde la importación de Packages para un componente en particular tenga algunos requisitos con otros Packages en otro componente. Esto significa que por ejemplo la importación de un Package de HR puede requerir la importación previa de un Package determinado del componente BASIS, o un Package de APPL. También puede suceder que aunque no sea un requisito cierto nivel de Package en otro componente de software, resultan efectos adversos. Estos efectos adversos (side-effects) son documentados en una Nota de SAP en cuanto son detectados. Para que podamos implementar las correcciones de manera consistente en los diferentes componentes de software, SAP recomienda importar los Packages usando Package Stacks. Packages Stacks son una combinación de Packages de diferentes componentes de software que incluyen un nivel determinado a cada componente y evita los inconvenientes de dependencias y efectos adversos descriptos anteriormente. Los Packages Stacks están disponibles para varias de las aplicaciones de SAP y para componentes de SAP Netweaver también. Adicionalmente a los Packages Stacks, también contienen actualizaciones para otros componentes, tales como actualizaciones del kernel del sistema. Esto es importante porque incluso puede ser necesario que actualicemos el kernel del sistema SAP para asegurarnos que no sucedan errores con un nuevo nivel determinado de Packages. En el Marketplace de SAP podemos consultar información sobre los Packages de los diferentes componentes de software de SAP así también como de los Stacks, como están conformados y también determinar los Packages que necesitaremos descargar para pasar del Stack actual al que necesitemos actualizar. El problema que surge frecuentemente es como actualizar un landscape complejo de SAP, así también como la duda de cómo utilizar los Package Stacks para una actualización ordenada y documentada. ¿Cuál es el nivel de actualización actual de mi landscape SAP? ¿Dónde puedo encontrar la información necesaria sobre Packages y Stacks? El Optimizador de Mantenimiento (Maintenance Optimizer) provee la solución a estas preguntas. Con el Optimizador de Mantenimiento pueden requerirse los

Package Stacks necesarios para el landascape definido en el Solution Manager en una forma controlada y gestionable. El Optimizador de Mantenimiento es mandatorio para algunos Packages y Stacks, tales como los Packages para SAP ECC 6.0 que fueron liberados a partir de Abril de 2007. Si queremos visualizar el estado actual de nivel de Packages para los componentes de software de nuestra implementación, podemos hacerlo desde cualquier pantalla de SAP, desde la opción de menú System → Status

Figura 107 - Estado de Sistema

Figura 108 – Información de Componentes de Software

Enhancement Packages Un upgrade de sistema, por ejemplo de SAP R/3 4.6C a SAP ECC 6.0, es un upgrade completo de sistema a una nueva versión. Luego del upgrade, el sistema funciona con todas las funciones de la nueva versión. Antes de que pueda ser utilizado en la operación de producción es necesario realizar muchos ajustes. Estos incluyen ajustes a modificaciones del estándar, cambios a customizing, cambios a desarrollos propios del cliente y mejoras. Las pruebas de aceptación necesarias también consumen gran parte del tiempo. Normalmente se necesita un período de varios meses para un proyecto de upgrade para un landscape de sistemas SAP. Esto lo hace que sea de un esfuerzo considerable de recursos y tiempo, por lo tanto costoso. Para reducir el costo y esfuerzo que involucra, SAP está cambiando paulatinamente a liberar los Enhancement Packages (EhP) para todas las aplicaciones. Esto comenzó con SAP ERP 6.0 en 2007 con el EhP 2. Enhancement Packages son nuevas versiones completas para un componente de software particular en el sistema SAP, en otras palabras, son upgrades parciales del sistema. El de Activación (Switch Framework) el cual está disponible a partir de AS ABAP 7.0 es usado para este propósito. Utilizando el de Activación, se pueden realizar cambios a los objetos de repositorio y no utilizarlos ya que necesitaremos activarlos en primer lugar. Esto significa que podemos importar un Enhancement Package para un componente de software en particular y mientras no activemos la o las funciones que incorpora este Enhancement Package desde el de Activación, el sistema seguirá funcionando como antes de la importación. Desde un punto de vista técnico, esto significa que un programa puede existir en el repositorio en diferentes estados al mismo tiempo. Por lo tanto cuando activamos la función desde el de Activación, lo que estamos haciendo es activar una determinada versión para los objetos de repositorio que dependen de esa función. La importación de Enhancemente Packages solamente no genera un esfuerzo considerable. Ahora es posible solo activar las funciones que van a ser requeridas desde el punto de vista funcional. Eso mantiene el esfuerzo requerido para la implementación y prueba de forma razonable.

Figura 109 – Enhancement Packages y Componentes de Software

Los Enhancement Packages son por lo tanto upgrades a componentes de software individuales, con la ventaja adicional de que podemos activar las nuevas funciones de una forma controlada y solamente cuando son necesarias. Las ventajas de los Enhancement Packages son: Procesos centrales estables Adaptación simple a requerimientos legales Tecnología estable Planificación y mantenimiento sencillo Disminución de upgrades de sistemas Nuevas funciones pueden ser implementadas selectivamente cuando son requeridas A diferencia de los Packages, los Enhancement Packages son acumulativos, lo que significa que no necesariamente debemos importarlos en secuencia. Por ejemplo, el Enhancement Package 4 para SAP ERP 6.0 contiene a Enhancement Package 2 y 3 por lo que podremos implementar directamente la última versión directamente. La importación de Enhancement Packages se realiza mediante la transacción SAINT, la cual es para la implementación y actualización de componentes de software. De todas formas, a partir de EhP 4 para SAP ERP 6.0 existe una herramienta externa llamada Ehpi (Enhancement Package Installer) para este propósito. Los Packages al estar vinculados con la versión del componente de software existen en diferentes niveles para cada versión de componente de software. Esto significa que luego de la implementación de Enhancement Package 2 para SAP ECC 6.0, los Packages que necesitaremos posteriormente deberán ser para SAP ECC 6.0 EhP 2

Lección 2: Configuración de Impresoras El configura las impresoras en el sistema SAP y monitorea la salida de los spool requests. Impresión en el Sistema SAP Existen varias clases de documentos en el sistema SAP, tales como listas de reportes, SAPscript o SAP Smart Forms. Aunque la manera en que se crean estos documentos es completamente diferente, la salida de impresión en papel de estos documentos siempre se realiza utilizando el mismo mecanismo de dos etapas: Primero un spool request es creado. El spool request contiene información de impresión independiente del dispositivo de salida e incluye información istrativa tal como autor, fecha, número de copias y la información que se va a imprimir. Solamente cuando el spool request va a ser direccionado a un dispositivo en particular un output request es creado. La información independiente de dispositivo del spool request es convertida al lenguaje particular de la impresora que comprende el dispositivo de salida seleccionado.

El configura las impresoras en el sistema SAP y monitorea la salida de los spool requests. Impresión en el Sistema SAP Existen varias clases de documentos en el sistema SAP, tales como listas de reportes, SAPscript o SAP Smart Forms. Aunque la manera en que se crean estos documentos es completamente diferente, la salida de impresión en papel de estos documentos siempre se realiza utilizando el mismo mecanismo de dos etapas: Primero un spool request es creado. El spool request contiene información de impresión independiente del dispositivo de salida e incluye información istrativa tal como autor, fecha, número de copias y la información que se va a imprimir. Solamente cuando el spool request va a ser direccionado a un dispositivo en particular un output request es creado. La información independiente de dispositivo del spool request es convertida al lenguaje particular de la impresora que comprende el dispositivo de salida seleccionado.

Figura 110 – Flujo de datos durante la impresión

Este proceso permite al visualizar el spool request antes de la salida. Puede haber muchos output requests para un spool request. Esto puede evitar que el tenga que recrear un spool request, si por ejemplo, el toner de la impresora está agotado o el papel incorrecto se encontraba en la bandeja. Por supuesto que también la impresión puede ser al mismo tiempo de la creación del spool request mediante la selección de la opción impresión inmediata (Print out immediately). El contenido real de un documento de un spool request se almacena en el TemSe (para objetos secuenciales temporales), el cual se define el lugar donde se almacenará mediante el parámetro rspo/store_location. Valor db (valor por defecto): El spool request se almacena en la tabla de base de datos TST03 (ventaja: se respalda junto con el backup de la base de datos)

Valor G: se almacena en el sistema operativo en el directorio global. (ventaja: mayor performance) Se puede especificar el lugar de almacenamiento individualmente para cada dispositivo de salida en la transacción SPAD (desde el menú Edit → Data Storage). La nota de SAP rspo/store_location.

20176

contiene

valores

adicionales

para

el

parámetro

La creación de un output request solicita al sistema de spool de SAP enviar información con un formato dependiente de la impresora seleccionada al sistema de spool del sistema operativo. Esto significa que el modelo de impresora elegida debe ser conocido por el sistema SAP. Definiciones de este tipo se conocen como tipos de dispositivos (device types). Si una impresora no puede ser controlada a nivel del sistema operativo, no puede ser usada en el sistema SAP tampoco. Hay varias maneras en la que un spool work process puede alcanzar a un spool del sistema operativo. Las conexiones más importantes, conocidas como métodos de (access methods) se explican a continuación en esta lección. Impresión Local

Figura 111 – Impresión Local

Una característica de la impresión local es que el spool work process y el sistema de spool del sistema operativo corren en el mismo servidor. No es relevante si la impresora está conectada directamente a este servidor o se alcanza a través de la red. El spool work process pasa la información de forma local, en el mismo servidor. En servidores UNIX, la impresión local se define con el método de L. En Microsoft Windows, se utiliza el método de C. La impresión local es la conexión más rápida y confiable desde el sistema SAP al sistema operativo. Tan pronto como el spool work process ha transferido la

información, puede tomar nuevos output requests, aún si el spool del sistema operativo se encuentra ocupado todavía. Se pueden configurar multiple spool work processes para una instancia SAP. Esto tiene consecuencias en la secuencia de salida. Spool Requests diferentes para la misma impresora podrían ser impresos en un orden distinto del que fueron creados. Si necesitamos que la salida de impresión respete la secuencia, podemos especificarlo para impresoras de forma individual. Sin embargo, una configuración de este tipo reduce la posibilidad de impresión en paralelo. Para más información sobre esto, podemos consultar la nota de SAP 108799. Impresión Remota En la impresión remota, el spool work process y el spool del sistema operativo están corriendo en diferentes hosts. De la misma manera que en la impresión local, es irrelevante desde el punto de vista del sistema SAP si la impresora se conecta directamente al host remoto o es a través de una conexión de red.

Figura 112 – Impresión Remota

Escenarios típicos para la impresión remota son: Impresoras de red que proveen su propio sistema de spool y son conectadas directamente a la red. Desde el sistema SAP se acceden mediante el método U con el nombre de la impresora. El método de U también es utilizado si el host remoto es un sistema UNIX. La nota 39405 describe como el método de U puede ser usado por las diferentes versiones de UNIX. SAP provee el programa SAPSprint para todos los hosts con sistemas operativos Windows. SAPSprint es un servicio de Windows. Cada output request se procesa en un hilo de ejecución separado. Los output requests de SAP que recibe SAPSprint del sistema SAP pueden ser transferidos a una impresora particular. Si la impresora no

está funcionando, esto no interrumpe la impresión de otros output requests en otras impresoras. El método de S es usualmente utilizado en este caso (protocolo SAP), pero el método de U también es soportado. Por razones de performance, solo deberíamos utilizar impresión remota en un entorno LAN y deberíamos asegurarnos que los spools de los sistemas operativos estén disponibles. Los s SAP pueden imprimir documentos en sus impresoras locales usando impresión en front-end. Estas impresoras locales no necesitan ser definidas en el sistema SAP. Si es necesario que el del sistema configure un dispositivo representativo para cada plataforma de sistema operativo de front-end.

Figura 113 Impresión en Front-end con Tecnología de Control (Método de G)

Desde la versión SAP Web AS 6.20, un nuevo procedimiento de impresión en front-end se encuentra disponible: impresión en front-end mediante tecnología de control con el método de G. Esto ya no requiere del programa SAPlpd. La ventana de impresión de Windows se llama directamente desde el control. El programa SAPlpd se instala junto con el programa SAP Logon. Los controles son DLLs que corren en el contexto de proceso de SAP GUI. El nuevo método de impresión recibe los datos de impresión y lo transfiere al sistema de impresión del sistema operativo. Una ventaja de este método frente al método F es que ofrece la ventaja de que puede ser utilizado también con SAP GUI para JAVA lo que hace que sea independiente de la plataforma del front-end. También puede ser utilizado con Windows Terminal Server. Información sobre impresión de front-end con tecnología de control está disponible en la nota de SAP 821519. Podemos definir el máximo número de spool work processes que pueden ser utilizados en el sistema SAP para impresión en front-end para cada instancia de SAP mediante el parámetro rdisp/wp_no_Fro_max (el valor por defecto es 1).

Este método de impresión no es recomendado para impresión masiva, sino más bien para impresión en impresoras locales de los s. Cuando usamos el método de F (para versiones hasta 4.6C), los datos de impresión se transfieren al host en donde el programa SAP GUI del está corriendo. Este método puede ser usado en PCs con diferentes sistemas operativos: En el caso de sistemas operativos de Microsoft Windows, el programa saplpd transfiere los datos recibidos al control de impresión de Windows. Si es necesario, saplpd se inicia automáticamente. Con otros sistemas operativos (Linux, Apple Macintosh, etc) los datos se transfieren directamente al sistema de spool del sistema operativo. En este caso, el nombre de la impresora debe especificarse en la definición del dispositivo. Para más información, puedes ver la Nota 128105. Si utilizamos SAP GUI para HTML y vamos a imprimir en los front-end, debemos utilizar el método de F. Usando este método, los datos de impresión son enviados al navegador y visualizados. Luego puede imprimirse el documento en el front-end.

Creación de Dispositivos de Salida La configuración del sistema de spool es una tarea del nistrador del sistema. La herramienta central para esto es la transacción SPAD (menú Tools → CCMS → Print → Spool istration)

Figura 114 – Creación de Dispositivos de Salida

Con impresión de front-end con tecnología de control (método de G), la impresora tiene un nombre genérico en SAP, y es asignada al dispositivo físico _DEFAULT. Como los modelos utilizados en las impresoras de front-end pueden ser muy variados, el dispositivo SWIN se asigna para las impresoras de los front-ends que utilizan Windows. Cuando se imprime con SAP GUI para JAVA en otros sistemas operativos, deberemos utilizar un dispositivo correspondiente, tal como PostScript. Si la impresión en front-end se realizará utilzando SAP GUI para HTML con el método de F, el dispositivo de tipo PDF1 debe seleccionarse. Los datos de impresión son luego transferidos al navegador en el front-end como un documento PostScript y puede ser impreso localmente.

Tabla 2 - Dispositivos de Salida para Impresión en Front-end

Para crear un dispositivo de salida, llamamos a la transacción SPAD y elegimos Output Device en la solapa Devices/Servers. Si hay un gran número de dispositivos en el sistema, podemos restringir la lista de devuelta con el campo de texto por ejemplo ingresando PR* (devolverá todas los dispositivos que comiencen con las letras PR) Dispositivo de Salida (Output Device): Nombre, máximo 30 caracteres. Nombre corto (Short Name): Para propósitos internos del sistema (puede generarse automáticamente) Tipo de Dispositivo (Device Type): Modelo de la impresora o familia compatible. Servidor de Spool (Spool Server): Servidor de aplicación SAP con spool work processes o un servidor lógico (veremos este concepto en la próxima lección) Lugar (Location): Por ejemplo, edificio u número de oficina. Sirve para que los s sepan donde se hará la impresión) Mensaje (Message): Utilizado temporalmente para sobrescribir al campo Lugar. Sirve para informar por ejemplo cuando está en mantenimiento el dispositivo) Impresora Bloqueada en el Sistema SAP (Lock Printer in SAP System): Los output requests para este dispositivo son creados pero no transferidos a la impresora. El recibe un mensaje: sin impresión inmediata. Método de (Host Spool Access Method): como un spool work process a al sistema de spool del sistema operativo. Host de Impresora (Host Printer): Nombre de la impresora a nivel del sistema operativo. Este nombre es dependiente de minúsculas y mayúsculas. En Windows, no debe haber espacios en el nombre de impresora. Nombre de Host (Host Name): solo para impresión local, se calcula automáticamente del servidor de spool. Host Destino (Destination Host): solo para impresión remota. Nombre del host en el cual el spool del sistema operativo está corriendo.

Tipos de Dispositivos El sistema SAP utiliza un tipo de dispositivo para formatear la información de impresión a un dispositivo específico. Cuando se hace referencia a un dispositivo de salida en el ambiente de SAP, no necesariamente significa una impresora. Un dispositivo de salida puede ser, por ejemplo, un Sistema de Gestión de Salida o un Sistema de Archivado. Cuando el spool work process genera un output request, utiliza las especificaciones del tipo de dispositivo. Esto es, el tipo de dispositivo describe como la impresión de datos debería ser formateada para un dispositivo en particular. La siguiente figura ilustra como un dispositivo de salida es creado:

Figura 115 – Dispositivo de Salida

La siguiente lista explica los términos de la figura. Formato de Página (Page Format): Un formato de página describe el formato de una página imprimible en el sistema SAP. Un gran número de formatos de páginas estándar son predefinidos en el sistema. Si un dispositivo va a soportar formatos adicionales, podemos definir nuevos formatos. Hay que considerar que cuando hacemos esto, el dispositivo de salida que vamos a utilizar debe soportar el formato definido. Tipo de Formato (Format Type): Un tipo de formato describe como la salida debería aparecer en el papel. Principalmente contiene el formato para la página. Formato (Format): Un formato es una implementación de un tipo de formato específico para un dispositivo. Esto es, el sistema SAP puede usar la descripción en un formato para controlar un dispositivo correctamente. Por ejemplo, realizar una salida

en una página con el formato de Carta. Un tipo de formato es por lo tanto independiente del dispostivo; el formato, por otro lado es una implementación específica de dispositivo para un tipo de formato. Set de Caracteres (Character Set): Un set de caracteres contine los caracteres que pueden ser utilizados por un dispositivo de salida particular. Significa, que para poder usar un set de caraceteres particular para un modelo de impresora en el sistema SAP, el tipo de dispositivo asignado al modelo de impresora debe contener este set de caracteres. Control de Impresión (Print Control): Permite el control de la visualización de opciones de los dispositivos de salida, tal como el cambio de tamaño de fuente, o la misma fuente. El control de impresión utiliza un control de secuencia de caracteres específico del dispositivo. Esto significa que para crear nuevos dispositivos, las opciones de visualización ofrecidas por el sistema SAP deben ser almacenadas con el control de secuencia de caracteres que el modelo de impresora elegido soporta.

Lección 3: istración de Spool Servers Concepto de Spool Server Lógico

El concepto de impresión mostró hasta acá un idea de una asignación fija de un dispositivo de salida a un servidor de spool. Un servidor de spool, por otro lado, pude ser asignado a múltiples dispositivos de salida lo cual incrementa el riesgo de sobrecarga en este servidor o también de no disponer de muchas impresoras si una instancia no se encuentra operativa. Por estos motivos sería convenientes tener un mecanismo para balancear la carga entre varios servidores de aplicación SAP. La inclusión de servidores lógicos en el planeamiento de impresión para el landscape de SAP desde un primer momento puede ahorrar mucho esfuerzo en el mantenimiento de la operación. Cuando el sistema SAP se escala en el tiempo con instancias adicionales y spool work processes se ponen a disposición, los servidores de spool lógico facilitan la adaptación del landscape de impresión.

Figura 116 – Servidores de Spool

Un servidor de spool es un servidor de aplicación SAP con al menos un spool work process. Cada output request es procesado en un servidor de spool real de este tipo. Un dispositivo de salida es creado en el sistema SAP y se asigna a un servidor de spool directamente. Sin embargo, existen varias ventajas asociadas con una capa adicional lógica entre el dispositivo de salida y el servidor de spool. Podemos utilizar servidores de spool lógicos para este propósito. Podemos clasificar dispositivos de salida y servidores de spool, por ejemplo, para impresión de test o impresión de producción. El sistema SAP verifica la clasificación y muestra mensajes de advertencia si encuentra una desviación. Por ejemplo, el sistema advierte si intentamos imprimir un gran volumen en un servidor de impresión productivo. Podemos mantener los servidores de spool en la transacción SPAD mediante la selección de Spool Servers en la solapa Devices/Servers. Información importante de un servidor de spool: Nombre de Servidor (Server Name): Nombre del servidor de spool, máximo de 20 caracteres y depende si es mayúsculas o minúsculas. El siguiente campo es para una descripción breve. Clase de Servidor (Server Class): Clasificación del spool server, por ejemplo: impresión masiva. Servidor Lógico (Logical Server): seleccionamos esta opción cuando creamos un servidor lógico. Mapeo (Mapping): Nombre de un servidor lógico real al cual este servidor lógico refiere.

Figura 117 – Creación de Servidor Lógico de Spool

Se puede definir un servidor de spool (lógico o real) especificamente para impresión en

front-ends. Si especificamos el parámetro de perfil rspo/local_print/server con el nombre del servidor de spool. Si vamos a tener una carga siginificante de impresión en front-end, podemos configurar al menos un spool work process adicional por cada servidor de spool de impresión de front-end para otras tareas. Como se mencionó antes, es posible clasificar dispositivos de salida y servidores de spool. Para clasificar un dispositivo de salida, tendremos que seleccionarlo en la transacción SPAD, bajo Output Devices y seleccionar el menú Edit → Classification. Ventajas de los Servidores de Spool Lógicos Cuando creamos un servidor de spool, ya sea un servidor lógico o un servidor real, podemos especificar un servidor alternativo. Si el servidor normal no está disponible, el sistema SAP intenta usar el alternativo.

Figura 118 – Alternativas de Servidores de Spool

Debemos asegurarnos que todas las impresoras que podrían ser usadas por un servidor de spool diferentes puedan ser controladas de la misma manera por cada servidor de spool. Por ejemplo, si el dispositivo de salida Test 1 en el ejemplo de la figura apunta a una impresora del sistema operativo P42 que es controlada localmente, una impresora a nivel del sistema operativo P42 debe existir en los servidores twdf5000 y twdf5001. No podemos definir más de dos servidores de spool para un servidor lógico. Pero como si puede referenciar a otro servidor lógico, es posible configurar jerarquías extensivas de servidores se spool. O sea configuraciones en cascada de servidores lógicos haciendo referencia a un servidor de spool y como alternativa a otro servidor lógico. Balanceo de Carga Podemos permitir balanceo de carga para cada servidor de spool con un servidor alternativo (para esto debemos elegir la opción Allow Load Balancing). La carga de un servidor de spool es calculada con el número de spool work processes, output requests y páginas a imprimir.

Figura 119 – Balanceo de Carga

Para un output request para un servidor de spool con balanceo de carga (la configuración puede ser para servidores lógicos y para servidores de spool), el sistema determina el servidor con la menor carga. El algoritmo es recursivo: el mismo criterio de selección es utilizado en el servidor mapeado y en el servidor alternativo (ambos podrían ser servidores lógicos también). Procesamiento de solicitudes secuenciales (propiedad de un dispositivo de salida) tiene prioridad sobre el balanceo de carga mostrado aquí (propiedad de un servidor de spool). Esto significa que el output request para un dispositivo de salida con procesamiento de solicitudes secuenciales no será distribuido en concordancia con la carga de trabajo, aunque sea asignado a un servidor de spool con balanceo de carga.

Transportando el Landscape de Impresión El concepto de servidores lógicos soporta una definición de un landscape de impresión consistente y transportable. A diferencia de servidores de spool reales, los servidore lógicos pueden tener el mismo nombre en varios sistemas SAP. De esta forma, podemos definir una arquitectura de impresión en SAP en el sistema de desarrollo y luego transportarla a los demás sistemas. Luego de transportar, todo lo que necesitaremos hacer es ajustar el mapeo de los servidores lógicos a los servidores de spool del nuevo sistema.

Figura 120 – Transportando el Landscape de Impresión

Existen funciones para el transporte manual de dispositivos de salida y de servidores de spool en la transacción SPAD.

Lección 4: Jobs de Background ¿Qué es el procesamiento en background o de fondo? El procesamiento en background debería esencialmente separar tareas periódicas y que insumen mucho tiempo de aquellas de interacción de s. Tareas que requieran mucho tiempo y ocuparían un work process en diálogo pueden ser secuencialmente procesadas en background sin afectar la performance de diálogo. Un requisito importante para conseguir este objetivo es un dimensionamiento apropiado del sistema, ya que, demasiados procesos de background podrían terminar compitiendo por recursos compartidos con procesos de diálogo (memoria principal, U). Los programas que deban ejecutarse regularmente y consuman mucho tiempo son planificados como Jobs de background en el sistema SAP. El planifica los Jobs de background y monitorea la correcta ejecución de los mismos.

Fundamentos Las siguientes preguntas responderemos en esta lección: ¿Por qué necesitamos procesamiento en background? ¿Qué es un Job de background? ¿Qué podemos realizar en background? ¿Qué condiciones de inicio existen? ¿Cómo son planificados y monitoreados los Jobs? ¿Qué estados puede tener un Job?

Figura 121 – ¿Por qué es necesario el Procesamiento en Background?

Work processes de diálogo deberían estar disponibles para responder a las solicitudes de los s rápidamente. Los recursos de diálogo deberían por lo tanto no ser

utilizados para ejecuciones prolongadas ya que pueden provocar cuellos de botella en el tiempo de respuesta de diálogo. El parámetro rdisp/max_wprun_time existe por este motivo justamente. Limita el máximo tiempo de ejecución de un paso de diálogo en un work process de diálogo. Esto debería asegurar que los procesos de diálogo no sean bloqueados por programas que requieren demasiado tiempo de ejecución, interfiriendo la operación online. Luego de que el máximo tiempo se ha superado, el programa es terminado. La manera en que el parámetro rdisp/max_wprun_time funciona está descrito en la nota de SAP 25528. Podemos utilizar los procesos de background para tareas que consuman mucho tiempo. También se conocen estos como procesos de batch. Normalmente, los procesos de background no se utilizan solamente para ejecuciones largas, sino que también para tareas repetitivas. Ejemplos de estas son los backups diarios de base de datos o los cierres de mes financieros y contables.

Figura 122 – ¿Qué es un Job de Background?

Un job de background consiste de uno o más pasos (steps). Un paso puede ser: Un programa ABAP Un comando externo Un programa externo Cada job se procesa sin interrupción por un único background work process. Los jobs de background pueden ser planificados con diferentes prioridades: Clase A (Prioridad alta) Clase B (Prioridad media)

Clase C (Prioridad normal) Si un job es planificado para ser ejecutado en un servidor particular o un grupo de servidores, este tendrá preferencia con respecto a otros jobs de la misma clase. Esta preferencia solamente aplica si múltiples jobs con la misma prioridad solicitan el procesamiento en background al mismo tiempo, por ejemplo, porque se planificaron para que se ejecuten a la misma hora. Deberíamos asegurarnos que la mayor parte de los jobs de background sean planificados con prioridad normal, clase C, sin especificación de servidor de ejecución. Esto debería aplicar para el 90% o más de todas las tareas de background.

Figura 123 – ¿Qué Podemos Ejecutar en Background?

Un paso dentro de un job puede ejecutar una de estas tres acciones: Un programa ABAP pude planificarse como un paso de un job. Si el programa ABAP tiene una o más pantallas de selección, tendremos que crear las entradas previamente en una variante. Una variante hace posible ejecutar un programa ABAP en background aunque el programa requiera valores de entrada. Los valores almacenados en la variante son luego utilizados durante la ejecución del programa. Si un programa ABAP tiene una pantalla de salida como resultado, esto es dirigido a una lista de spool. Podríamos también especificar un recipiente de email para esta lista de spool durante la definición del job. Debemos especificar una impresora para la creación de la lista de spool, aunque no necesariamente tenga que ser impreso en un dispositivo de salida como resultado del procesamiento en background. Esto por ejemplo podría hacerse posteriormente. Un comando externo es un llamado a un script predefinido, un comando, o un programa a nivel del sistema operativo. Con comandos externos, podemos enmascarar llamadas al sistema operativo y guardarlos en el sistema SAP bajo un nombre. Podemos usar también el concepto de autorización de SAP para proteger la ejecución de un comando externo. Esto permite que podamos determinar que s están permitidos a ejecutar que comandos externos (sobre que servidores y/o sistemas operativos)

Un programa externo es un comando del sistema operativo. El concepto de autorización de SAP solamente especifica si un puede llamar un programa externo o no. Una asignación más detallada de autorizaciones, por ejemplo a nivel de los nombres de programa, no es provista con la ejecución de programas externos. Utilicemos comandos externos para esto.

Figura 124– Criterios de Inicio de un Job de Background

Un job puede ser iniciado: Mediante la planificación en una fecha y hora particular (esto incluye el inicio inmediato, si no hay background work processes libres disponibles al momento en que debe iniciar el job según la planificación) Mediante la ocurrencia de un evento particular definido en el sistema SAP. Esto incluye jobs que se iniciarán luego de la finalización de otros jobs o en los cambios de modo de operación o jobs con inicio inmediato si existen background work processes libres al momento.

Planificación y Monitoreo Podemos utilizar la transacción SM36 para definir nuevos Jobs. Puedes también llamar el Asistente de Job, transacción SM36WIZ o desde la transacción SM36 también.

Figura 125 – Planificación de Jobs

Las especificaciones que requiere la definición de un job son: Especificaciones generales tales como nombre de job, prioridad del job (por defecto: C) y opcionalmente un servidor de ejecución o grupo. Definición de uno o más pasos Definición de una condición de inicio (de tiempo o controlada por evento) El Asistente de Job nos ayuda en la creación del job guiándonos de manera fácil a través del proceso de creación. El método de creación de un job de background (clásico o mediante el Asistente de Job) no tiene incidencia en el resultado. Algunas funciones (especificar el SAP en la definición del paso de job, modificación del orden de ejecución de los pasos) no están disponibles para el Asistente de Job. La transacción SM37 nos permite monitorear los jobs. Podemos seleccionar los jobs utilizando diversos criterios en la pantalla inicial de esta transacción. Algunas opciones serían visualizar los jobs que contienen un paso determinado, que tienen un estado particular o que reaccionan a un evento definido.

Figura 126 – Monitoreo de Jobs

Luego de que seleccionamos Execute, una vista de job aparece que es creada por el Visor de Listas SAP (SAP List Viewer: ALV). Seleccionando del menú Settings podemos determinar las columnas que se mostrarán y el orden, entre otras cosas. Podemos también configurar si será el diseño (layout) estándar para el actual o todos los s. Para el análisis de jobs, una columna que no se visualiza por defecto y es importante, es la columna de servidor de ejecución. Muchas veces algún problema en la ejecución de un job puede estar relacionado al servidor de aplicación donde se ejecuta. Podemos también navegar a otras vistas específicas del job desde la visualización de job mostrada en la figura: Lista de Spool contiene las listas de salida de los programas de ABAP (si es que existen) Detalle del Job contiene, entre otras cosas, información sobre la definición del job, duración del procesamiento del job y la fecha y hora de inicio del job. Todos los mensajes de salida por un programa de background son almacenados en el log del job. Podemos visualizar el log para obtener información sobre un programa que finalizó con error o para realizar una investigación detallada sobre la ejecución de un job de background.

Figura 127 - Estados de un Job

Un job puede tener los siguientes estados: Planificado (Scheduled): Los pasos que requieren la creación del job han sido definidos ya, de todas formas la condición de inicio aún necesita ser definida. Liberado (Released): El job ha sido completamente definido, incluyendo la condición de inicio. Un job no puede ser liberado sin una condición de inicio. Solamente un o un con las autorizaciones necesarias para el procesamiento de background puede liberar un job. Esto asegura que s sin autorización no puedan ejecutar jobs sin aprobación. Listo (Ready): La condición de inicio de un job liberado se ha cumplido. Sin embargo el job se encuentra en la cola de espera por un work process de background libre. Activo (Active): El job está siendo ejecutado y no puede ser borrado ni modificado. Si un job activo no se ejecuta normalmente, por ejemplo, demora mucho más del tiempo normal, podemos analizar el job en modo de depuración. Luego podemos finalizar el job definitivamente o liberarlo nuevamente. Para esto, en la transacción SM37, seleccionamos Job → Capture: active job. Para capturar un job de background, debemos iniciar sesión en el servidor SAP donde el job está corriendo. Finalizado (Finished): todos los pasos del job fueron ejecutados sin problemas. Cancelado (Canceled): El job finaliza anormalmente, esto puede suceder de dos maneras:

1. El deliberadamente termina el job en la transacción SM37 mediante la selección de Job → Cancel active job. 2. Un paso del job terminó con error. Podemos modificar un job mientras este tenga los estados Planificado o Liberado. Si la ejecución de un job ya ha comenzado, podemos monitorear el procesamiento en el log del job. Si el job tiene programas ABAP que crean listas de salida, estas se almacenan en las listas de spool. Podemos crear un nuevo job copiando otro existente. Desde el menú selecciona Job → Copy.

Lección 5: istración de Jobs Planificación Basada en Tiempo

Figura 128 – Inicio Dependiente de Tiempo de un Job

Un job puede ser iniciado de forma dependiente de tiempo o de un evento. En el caso de inicio basado en tiempo, podemos seleccionar entre las siguientes opciones: El job debe ejecutarse inmediatamente. El job debe ser ejecutado en una fecha y hora particular. El job debe ejecutarse en un día laboral determinado. Puedes seleccionar que el job sea recurrente. Esto significa que el job será ejecutado nuevamente después de un período de tiempo definido. También es posible especificar excepciones, tal como posponer al siguiente día laboral en el caso de un feriado en el calendario.

El job es iniciado en la fecha y hora indicado, en concordancia con la prioridad del job y disponibilidad de work processes de background. Puedes especificar también un período de tiempo en el cual el job debe iniciarse. Para esto, especificamos un tiempo luego del cual el job no debe ejecutarse. Con esta función, podemos prevenir la ejecución de jobs periódicos en un momento no conveniente, entre otras cosas. Por ejemplo, un job de reorganización que debería solamente ejecutarse durante la noche demora su inicio por falta de disponibilidad de work process de background. Con una ventana de tiempo de inicio, podremos evitar que este job se ejecute durante el día, cuando los s de diálogo están activos y hay menos recursos disponibles. Balanceo de Carga El parámetro de perfil rdisp/bctime especifica el período de tiempo en el cual el planificador de jobs dependientes de tiempo está activo (observar la Figura 129). La ejecución de jobs con una condición de inicio inmediata usualmente evita el planificador. En este caso, el work process de diálogo del que solicita el inicio inmediato es quien planifica el job. Solo si no hay recursos libres, el job es planificado de forma basada en tiempo. La fecha y hora planificada de inicio corresponde al momento en el tiempo en el que debería haber iniciado.

Figura 129 – Planificando Jobs y Balanceo de Carga

Los work processes de background pueden ser configurados en cada instancia del sistema SAP utilizando el parámetro de perfil rdisp/wp_no_btc. El número de work processes requeridos en el sistema SAP depende del número de tareas que se realizarán en batch. Si el sistema de transporte es utilizado, debe haber al menos dos work processes de background en el sistema. La combinación de job ID y el nombre de job definen el job de manera univoca en el sistema. En cada instancia SAP en la que existen work processes de background definidos, el planificador de job basado en tiempo corre cada la cantidad de segundos definido en

ridsp/btctime (el valor por defecto es 60). Este es un programa ABAP (SAPMSSY2) que corre automáticamente en un work process de diálogo. A partir de SAP Netweaver 7.0 el planificador de job también se inicia luego de que un job ha finalizado. Esto incrementa la tasa de salida para el procesamiento de background considerablemente dependiendo de cuantos jobs hay planificados y recursos disponibles. La nota de SAP 923228 describe como podemos activar esto para sistemas SAP con una versión a partir de Basis de 4.6C. El planificador de job basado en tiempo verifica la tabla de planificación de jobs en la base de datos y busca jobs que estén esperando a ser ejecutados. Estos jobs son transferidos a work processes de background que se encuentren libres en la instancia de SAP, de acuerdo a la prioridad y servidor de ejecución. Los jobs que no son asignados a ningún servidor en particular para la ejecución pueden ser ejecutados con cualquier work process de background libre. Esto significa que la carga de trabajo es automáticamente distribuida entre las instancias SAP. Si un job es explícitamente asignado a ser ejecutado ya sea en una instancia seleccionada o un grupo de instancias algunas características particulares se derivan de esto, tal como asegurarnos que el job se ejecuta en un sistema operativo particular o en el mismo servidor donde corre la base de datos. Esto significa, de todas maneras, que no contamos con la ventaja de la distribución de carga automática del sistema.

Jobs Estándar Los jobs estándar son jobs de background que deberían ejecutarse regularmente en un sistema de producción SAP. Estos jobs principalmente realizan ciertas tareas de limpieza en el sistema, tal como el borrado de spool requests obsoletos o el procesamiento de información estadística y de monitoreo.

Figura 130 – Planificación de Jobs Estándar

En la transacción de definición de jobs (SM36), puedes acceder a una selección de jobs estándar importantes que puedes planificar, monitorear y editar seleccionando Standard Jobs. Si queremos planificar todos los jobs estándar, seleccionamos Default Scheduling. Todos los jobs estándar que están definidos en la tabla REORGJOBS son planificados con una variante y período específico. Para planificar jobs individuales, selecciona el job y especifica el período de ejecución. Para definir un job estándar adicional que no está disponible en la selección (tabla REORGJOBS), podemos seleccionar Predefine new job. Para información sobre jobs estándar, podemos consultar las notas 16083 – Standard Jobs, reorganization jobs y 1034532 – Changes for standard jobs.

Planificación Basada en Eventos Un evento es una señal para el sistema de procesamiento en background que indica que un estado particular se ha alcanzado en el sistema SAP. El sistema de procesamiento en background recibe eventos y luego inicia todos los jobs que están vinculados a este evento.

Figura 131 – Inicio de Jobs Dependiente de Eventos

Un job dependiente de evento puede ser planificado con una de las siguientes condiciones de inicio: Luego de un Evento: El job inicia después de que un evento definido en el sistema SAP es recibido. Modo de Operación: Con esta opción, puedes vincular un job a la activación de un modo de operación cuando planificamos el job.

Luego de un Job: De esta manera, podemos crear cadenas simples de jobs donde la ejecución del job sucesor pude ser dependiente del estado con el que finalizó el job predecesor. Eventos Nuevos eventos son definidos por el de sistema en CCMS, transacción SM62. Cuando se hace esto, el diferencia entre eventos de sistema y eventos de . Los eventos de sistema son predefinidos por SAP y no deberíamos modificar o disparar.

Figura 132 – Definición y Disparo de Eventos

Los eventos pueden ser disparados de diferentes formas: Manualmente en CCMS para propósitos de prueba (transacción SM64). Con un programa ABAP, mediante el uso del módulo de función BP_EVENT_RAISE o el método RAISE de la clase CL_BATCH_EVENT. Fuera del sistema SAP a nivel del sistema operativo usando el programa sapevt. Un parámetro puede también ser transferido cuando un evento se dispara. De esta manera, podremos definir jobs que esperan por la ocurrencia del evento junto con el parámetro específico. También podemos acceder al Historial de Eventos en la transacción SM62. La sintaxis del programa sapevt es: sapevt <parameters> <Parameters> are multiple individual switches based on: {<EventID> | event=<EventID>} [{-p <EventParam>} | param=<EventParam<´>] [-t[0|1|2][a]] [-v] {[name=<SystemName>] [msserv=<MsServ>] [mshost=<MsHost>] [pf= ]} {[timeout=<TimeOut>]} [-? | /? | -help | /help]

La nota de SAP 802172 explica los parámetros en detalle. La salida de sapevt se escribe a un archivo de traza dev_evt. Para que pueda reaccionar a eventos externos, el sistema SAP debe estar activo. De otra manera, un evento que se haya disparado por un programa externo se pierde. Un ejemplo de ejecución del programa event=NUEVO_ARCHIVO_INTERFAZ name=DEV

sapevt podría ser: sapevt mshost=twdf5000.wdf.sap.corp.

Si el nombre del evento contiene espacios, deberemos utilizar comillas (“”) cuando llamamos al programa sapevt. Por ejemplo: sapevt "MY EVENT" name=QAS mshost=twdf9999.wdf.sap.corp

Lección 6: Otros Temas de Procesamiento en Background Reserva para Jobs de Clase A En la operación normal, cada work process de background procesa jobs de todas las prioridades. De todas formas, podemos reservar tantos work processes de background configurados como deseemos para jobs de prioridad alta, o sea, jobs de clase A. La reservación de work processes para jobs de clase A no reserva ningún work process en particular. Más bien, el sistema asegura que una cantidad determinada de work processes de background se mantengan libres. Los jobs de clase B y C pueden solamente ser iniciados si el número definido de work processes para posibles jobs de clase A se mantiene libre.

Figura 133 – Reserva de Jobs de Clase A

Para configurar el número de work processes de background de clase A tendremos que configurar los modos de operación en la transacción RZ04. Cuando hacemos esto, tendremos la opción de reservar work processes de background. Si la carga de jobs de clase A es pequeña, o cuellos de botella raramente ocurre en el procesamiento de background, en otras palabara, al menos un work process de background casi siempre se encuentra libre, la reserva de work processes para jobs de clase A probablemente no ofrezca ventajas. En este caso, la reservación simplemente significará que un work process es muy poco utilizado (solo por jobs de clase A).

SAP recomienda que no reservemos más de un work process de background para el procesamiento de jobs de clase A por cada instancia del sistema. Con esto usualmente es suficiente para un escenario de planificación de jobs de background. Objetivos de Ejecución Solamente instancias con work processes de background o un grupo de servidores de job puede ser utilizado para planificar la ejecución de jobs con instancias o grupos específicos. Un grupo de servidores de job contiene una o más instancias con work processes de background. Los grupos de este tipo pueden ser utilizados de la misma forma que los grupo de logon para s de diálogo. También es posible procesar tareas de background en instancias seleccionadas.

Figura 134- Ejecución en instancias o grupos de servidores de job

Podemos configurar un grupo de servidores de job en la transacción SM61 (menú Tools CCMS → Background Processing → Background Objects). Aquí podremos definir grupos de servidores con work processes de background asignando las instancias que formarán el grupo. s de Background Con la clásica definición de jobs utilizando la transacción SM36, podemos asignar cada paso de un job a un (observar la Figura 135). El especificado es utilizado para las verificaciones de autorización durante la ejecución del paso. Por defecto, el nombre del que está definiendo el job aparece, y el job luego será ejecutado usando las autorizaciones que ese tenga. Si el job no debería ejecutarse usando las autorizaciones de ese , podemos ingresar un diferente. Para poder hacer este cambio, deberemos contar con la autorización pertinente S_BTCH_NAM para poder ingresar otros s diferentes al nuestro en el campo en la definición del paso.

Figura 135 – s de Background

Es útil configurar s de background para varias áreas de trabajo que cuenten con las autorizaciones necesarias para las actividades que se requieran, y que puedan ser usadas por s con las mismas autorizaciones para planificar jobs de background en esta área de trabajo, tal como la istración de sistema. Los s de background tienen registros maestros de que cuentan específicamente con autorizaciones para el procesamiento de background. El tipo de de Sistema (System) debe ser elegido cuando creamos s de background. Un logon al sistema de diálogo no es posible con este tipo de s. De la misma manera, los s de este tipo están exentos de la configuración de validez de las contraseñas. El de sistema solo puede cambiar la contraseña mediante la transacción SU01. Si en cambio usamos el Asistente de Jobs para la creación de los mismos, no tenemos la posibilidad de definir un diferente para cada paso del job.

Utilización de Programas Externos El sistema de procesamiento en background diferencia entre comandos externos para s normales y programas externos para los es de sistema. El propósito de esta diferenciación es darle a los es del sistema la posibilidad de ejecutar cualquier programa externo que requieran, mientras que los s normales están restringidos al uso de comandos externos para los cuales hay verificaciones de autorización. En ambos casos, el programa sapxpg es invocado a nivel del sistema operativo e inicia el programa relevante en el sistema operativo.

Figura 136 – Utilizando Programas Externos

Los Comandos Externos son commandos o programas del host predefinidos en el sistema SAP por el . Estos están protegidos por autorizaciones por lo que los s normales pueden solamente planificar los comandos para los cuales el les ha asignado las autorizaciones necesarias. De esta manera, podemos proveer de funciones fuera del sistema SAP, a nivel del sistema operativo, a los s del sistema SAP. Los Programas Externos son comandos sin restricciones que no son predefinidos o restringidos por autorizaciones. Un que tenga autorizaciones de puede ingresar un programa externo en un paso de un job. Ninguna verificación de autorización SAP se lleva a cabo antes de la ejecución del comando. Los programas externos proveen al la flexibilidad para ejecutar cualquier comando en el sistema operativo en el sistema SAP sin preparación previa. Un de sistema debe contar con autorizaciones para el objeto S_RZL_: de Procesamiento en Background.

Figura 137 – Definición y Uso de Comandos Externos

La creación de comandos externos requiere de los siguientes pasos: 1. Llamar a la transacción SM69. 2. Seleccionar Create. 3. Realizar las entradas en el nuevo comando. Los comando externos son identificados unívocamente con un nombre, comenzando con Z o Y, y un tipo de sistema operativo. El campo Type se completa automáticamente. Especificar un comando ejecutable del sistema operativo (si es necesario con la ruta completa) y especificar cualquier parámetro requerido u opcional. Seleccionar el cuadro de verificación (checkbox) Additional Parameters Allowed si los s podrán especificar parámetros adicionales cuando ejecutan el comando externo. Los parámetros adicionales son agregados en una cadena de parámetros especificados bajo el campo Parameters for Operating System Command. El campo Trace debería dejarse en blanco usualmente. Para seguir la ejecución de un comando externo, utiliza el parámetro de traza para el módulo de función SXPG_COMMAND_EXECUTE. Si se ha definido una verificación adicional de autorización, ingrese el nombre del módulo de función que realiza la verificación en el campo Check Module. Este es usualmente una copia del módulo de función SXPG_DUMMY_COMMAND_CHECK. El sistema llama al módulo de función automáticamente si un intenta ejecutar el comando externo o lo planifica en un paso de job de background. 4. Guarda el comando. Para regresar a la vista de comandos, selecciona Back.

Indicadores de Control (Control Flags) Es posible realizar especificaciones sobre la tarea y otras opciones de ejecución usando indicadores de control. Usualmente no es necesario cambiar los valores por defecto. Por ejemplo, podemos especificar: Si el proceso va a ser registrado. Si Los datos de salida se escriben al log del job tal como son devueltos por el programa externo. También es posible registrar información adicional sobre el programa externo en el log del job.

Figura 138 – Indicadores de Control para Programas o Comandos Externos

Otro indicador es si el paso del job espera por la finalización del programa externo. En el caso de que después de que hemos iniciado un servicio con el sistema de procesamiento en background, tal como un demonio en UNIX o un servicio en Windows, el programa se mantiene activo luego del inicio. Estos programas iniciados como servicio o demonios no devuelven el control al sistema de procesamiento en background de SAP, como en el caso de otros programas. Si iniciamos un programa mediante un servicio, no deberíamos utilizar el indicador de control Job waiting for ext. Termination cuando planficamos el paso del job.

Lección 7: Monitoreo de Sistema La infraestructura de Monitoreo de Alertas - Permite realizar un monitoreo eficiente de los sistemas SAP

Recolección de Datos --> Cada subarea y componente de un sistema sap es monitoreado por un programa llamado recolector de datos, el cual chequea ciertos intervalos su componente y almacena la información obtenida en la memoria principal de la Instancia. Almacenamiento de Datos --> el área de la memoria q almacena toda la información se conoce como segmento de monitoreo, esta area es continuamente sobrescrita, los datos se copian a la BD para poder ser analizados posteriormente istración de Datos --> Los datos obtenidos en el monitoreo de segmento son analizados y evaluados tx - RZ20 Herramienta de visualización TX RZ20

Sap provee un set de monitores los cuales ya viene incluidos, dentro de un set de monitores se encuentran los monitores q este contienen, estos ofrecen diferentes vistas de los objetos de monitoreo de un sistema

Una vez q se ingresa al monitor se accede a las vistas de elementos del árbol de Monitor (MTE)

Cada nodo del árbol es un MTE lo cuales nos permiten organizar a los objetos de monitoreo dentro de categorías para facilitar la búsqueda y visualización de los objetos

Luego en las hojas del árbol se encuentran los atributos del objeto de monitoreo

Estos atributos son propios de cada objeto y almacenan los valores y almacenan los valores recolectados por los programas recolectores de datos

Haciendo doble clic al atributo que indica alguna alarma se ingresa al método de análisis

Las alertas se propagan si es severa por los niveles superiores del árbol, rojo es más severo q amarillo.

Cada atributo tiene una serie de propiedades para ajustar la generacion de alarmas a los requerimientos

En los atributos de performance es donde se definen los valores que generaran las alarmas de advertencia

Para poder configurar propios set de monitores se debe activar la función de mantenimiento

Luego de asignar los objetos, se da guardar para asignar un nombre

Luego de finalizar se desactiva la función de mantenimiento

Se pueden revisar que alarmas están abiertas

En el árbol se puede visualizar las alarmas q están pendientes por análisis

Haciendo doble clic sobre el atributo se verán las alarmas pendientes

Luego de q esta determinada la causa y efectuar la corrección se marca como alarma completa para que vuelva el indicar al estado normal.

istración Avanzada de Clientes Lección 1: Concepto Copia y Transporte de Clientes

Las copias de clientes pueden reemplazar datos en un cliente nuevo o en uno ya existente. Ingresar a la TX – SCC4 Para crear un nuevo cliente

Una vez creado el cliente, se ingresa a este mismo con el SAP* y la contraseña

Siempre que se crea un nuevo cliente, debe realizarse una copia desde un cliente de referencia, puede ser local o remoto: Copia Local entre clientes – en la copia local los datos se leen y se escriben en la misma BD, para todos los tipos de copias siempre la ejecución debe realizarse en el cliente destino, se debe seleccionar desde que cliente se quiere realizar la copia, para el caso de un nuevo mandante es recomendable realizar la copia desde el cliente 000 del sistema. Ingresar a la TX – SCCL

Luego debe elegirse el perfil para la copia, es decir que datos se copiaran desde el cliente origen hacia el nuevo cliente

Por último se observa la verificación antes de iniciar la copia donde se verán los datos del cliente destino, el perfil utilizado y el cliente origen, así también como un detalle de los datos que serán copiados según el perfil utilizado

Se podrá observar el progreso y los logs de la copia de mandante en la TX – SCC3

En la TX- Scc3 se puede ver no solo los logs del cliente en el que estamos logueados, si no también todos los clientes del sistema

Desde acá se podrá ingresar al detalle de los logs de las copias de los otros mandantes, es importante que mientras una copia este en ejecución no se trabaje ni en el cliente destino ni tampoco en el cliente origen

En el detalle, se podrá ver el estado del progreso de la copia, la acción actual que se está realizando y las estadísticas para la ejecución

Con el monitor se puede observar de forma gráfica el progreso de la cantidad de tablas copiadas así también como el tiempo

Con el detalle se puede analizar exactamente cada objeto que ha sido copiado desde el cliente origen.

En la TX SM37, se puede observar el progreso del job en ejecución

En la copia de cliente remota previamente a iniciar la copia, el sistema realizara una verificación de consistencia mediante las conexiones RFC

En el mandante destino desde la TX – SCC9, se realizara la copia remota de clientes, se selecciona un perfil, se debe tener en cuenta que si copiamos datos cross-client se podría afectar el resto de los mandantes que puedan existir en el sistema destino

Se debe seleccionar también una conexión RFC que tenga un con las suficientes autorizaciones para realizar la copia desde el sistema origen

Tanto en la copia local como remoto, podemos seleccionar la cantidad de procesos en paralelo para la ejecución, esto puede ayudar a reducir los tiempos de la copia

En la TX- SCC3, ver los logs de la copia

Se puede observar la acción de cada uno de los procesos escogidos

Otra opción para la copia es la exportación e importación, mediante la TX- SCC8 se exportara el cliente desde un sistema origen y luego con el sistema de transporte se importara en el sistema destino

Se debe seleccionar un perfil para la exportación, dependiendo del perfil seleccionado podremos generar hasta 3 archivos en el directorio de transportes del sistema origen, tenemos que tener en cuenta contar con el suficiente espacio para la exportación

También la información del sistema destino y el mandante destino, esta información será utilizada por el sistema de transportes luego para la importación La ventaja de este método es reproducible, una vez que exportamos el cliente se podrá importarlo en el mandante las veces que sea necesario, lo que es muy útil para un mandante que se usa de entrenamiento el cual podría actualizarse una vez por semana por ejemplo

En la copia remota como en la exportación podremos verificar de ante mano la consistencia con el sistema destino

Debemos contar con una conexión RFC al sistema destino

El resultado del chequeo de consistencias, podría advertir por ejemplo que exista una tabla con diferentes estructuras en el sistema origen y en el sistema destino

Antes de iniciar el proceso de exportación, se podrá verificar los datos que se han seleccionado, tener en cuenta que para este caso se utilizaran las herramientas del sistema transporte tal como el programa de transporte tp

Una ventana de información indicara que hasta 3 archivos se podrán generar dependiendo del perfil seleccionado, básicamente si se selecciona exportar datos crossclient desde el sistema origen, un tercer archivo se generara en el directorio de transportes

Al importar el mandante en el sistema destino, se utilizara la herramienta STMS, luego se debe realizar un post-procesamiento con la TX SCC7 en el mandante destino

Lección 2: Comparación de Clientes Usando la Herramienta de Comparación de Clientes Cuando varios sistemas SAP y clientes están siendo implementados, podría ser necesario comparar y ajustar el customizing entre diferentes sistemas y clientes. La función de comparación permite comparar y ajustar el contenido de una tabla o vista en dos clientes diferentes, mediante conexiones RFC.

Figura 138 – Comparación de Clientes

Para usar la función de comparación de clientes, desde la pantalla inicial de SAP, ingresa a la transacción SCU0. Podemos usar esta función para comparar: Un cliente con un cliente de referencia, tal como un cliente creado por nosotros o el cliente de SAP 000. Esto es especialmente útil después de un Upgrade o Importación de Lenguaje, ya que solamente el cliente 000 es provisto con datos de las tablas perteneciente a la clase de entrega CC. Comparar clientes durante un escenario de rollout. Por ejemplo, si las subsidiarias quisieran ajustar sus customizing con respecto al customizing de referencia de un Cliente Maestro. Comparar el customizing cross-client de distintos sistemas antes de combinar diferentes clientes en un mismo sistema en un escenario de roll-in. Por ejemplo, si las subsidiarias quisieran recibir los cambios de customizing desde un cliente de referencia, cliente maestro de la organización superior.

Figura 139 – Comparación de Clientes: Opciones de Selección

Para seleccionar los objetos a ser comparados en una comparación de clientes, podemos usar un método orientado a proyecto utilizando el IMG para definir los objetos. También podemos seleccionar desde los componentes de aplicación, listas de objetos y órdenes de transporte. También podemos elegir objetos manualmente. Para iniciar la comparación, utiliza la transacción SCU0 y el procesamiento en background. La transacción primero muestra un resumen de las tablas que pertenecen a vistas para el IMG, componente de aplicación u orden de transporte seleccionado. Luego de la comparación, el sistema crea una lista de las diferencias e indica si estas diferencias se encuentran en la estructura de las tablas o en el contenido. Para visualizar la diferencia de las entradas, selecciona un objeto. Esto permite realizar una comparación detallada.

La comparación de cliente es generalmente con otro sistema, por lo que en estos casos necesitaremos acceder mediante una RFC. Para más información sobre comparación de clientes, puedes consultar la Nota de SAP 91096 Los resultados de cada comparación es un resumen de las diferencias que existen entre el cliente donde nos encontramos y el cliente seleccionado para la comparación. Este resumen sirve como un punto de inicio para continuar con el análisis de las diferencias. El resultado de la comparación es almacenado en una lista de trabajo o de diferencias. Usando la Herramienta de Mantenimiento de Clientes Por cada objeto que es comparado, se lista con una descripción en la salida de la comparación. La información más importante es el indicador de estado. El indicador de estado informa la existencia y naturaleza de cualquier diferencia. El estado de procesamiento nos permite distinguir entre los objetos que han sido ya procesados o tratados, o sea, que han sido ajustados para igualarse entre ambos clientes y aquellos que todavía no. Este tipo de procesamiento se conoce también como ajuste del objeto. El estado de procesamiento se indica por un pequeño semáforo, donde rojo indica que no ha sido ajustado, amarillo significa que se está realizando el ajuste y verde que se ha completado. Una breve explicación sobre el estado de comparación y el estado de procesamiento se puede obtener mediante el ícono Legend.

Figura 140 – Ajustando Objetos de Customizing

Podemos ajustar un objeto por vez. Estos objetos que pueden ser ajustados son algunas de las tablas o vistas que pueden mantenerse a través de la transacción SM30. Todos los demás objetos solo pueden ser comparados. Para realizar un ajuste, desde la pantalla Comparison, selecciona Edit Interact Copy. La pantalla Overview Adjustment se visualiza, mostrando el detalle de las diferencias entre los dos clientes, registro por registro. A la izquierda de cada registro en esta lista de trabajo se encuentra el estado de comparación, el cual inidica si cada entrada de registro existe en el cliente comparado y en el cliente donde nos encontramos.

Figura 141 – Configuración de Cliente

La opción de cliente Protection: Client Copier and Client Comparsion Tool puede ser utilizada para prevenir que un cliente sea sobrescrito por una copia de cliente o una comparación y ajuste de cliente. También puede asegurar que los datos sensibles no puedan ser visualizados desde otro cliente durante una comparación. Para seleccionar esta opción desde la transacción SCC4, seleccionamos uno de los niveles de protección: Nivel 1: No overwriting Este nivel de protección asegura que el cliente no puede ser sobrescrito por el programa de copia de cliente. Esta opción debería utilizarse si en el cliente se realiza customizing o el cliente contiene configuraciones críticas o datos que no deberían sobrescribirse. Nivel 2: No overwirting and no external availability Este nivel de protección también protege contra la sobrescritura del cliente y contra el

a lectura desde otro cliente durante una copia de cliente o una comparación de customizing. Esta configuración debería utilizarse si el cliente contiene datos sensibles. Todos los clientes productivos deberían tener esta opción.

Importación de Ordenes de Transporte Para configurar el landscape de sistemas, es suficiente contar con un sistema SAP, tal como el de desarrollo; el sistema de calidad y producción no son requeridos en esta etapa. También deberemos crear un directorio de transportes a nivel del sistema operativo, si es que estará ubicado en un servidor distinto del primer sistema que instalemos. Este directorio es requerido por TMS.

Dependiendo del sistema operativo, el directorio de transportes global y todos los subdirectorios necesarios podrían ser creados automáticamente durante la instalación del sistema SAP (ver la guía de instalación para el sistema SAP para más detalles). Los transportes nos permiten sincronizar el Customizing y los desarrollos en múltiples sistemas SAP a través de la transferencia de los cambios realizados desde el sistema de desarrollo a los sistemas subsiguientes. Los transportes a través de las rutas de transportes deben ocurrir solo en una dirección.

Conceptos y Terminología de TMS Los conceptos detrás de TMS (Transport Management System): Configuración centralizada del Sistema de Cambios y Transportes (CTS) para todos los sistemas SAP. Gestión centralizada de órdenes de transportes y del proceso de importación. Estrategia de transportes basada en rutas de transportes predefinidas. TMS El propósito de TMS, el cual se accede mediante la transacción STMS, es controlar de forma central la propagación de los cambios a través de los sistemas del landscape basado en caminos predefinidos. Esto está diseñado para asegurar la consistencia del repositorio de SAP y el contenido de las tablas de Customizing en todos los sistemas del landscape. Con TMS podemos: Definir el rol de un sistema SAP dentro de un landscape de sistemas o un dominio de transportes. Configurar las rutas de transportes mediante un editor o usando configuraciones estándar. Configurar los parámetros del programa de transportes tp Visualizar las colas de importación de todos los sistemas en el dominio de transportes. Definir los procedimientos de aseguramiento de calidad y aceptación de cambios en el sistema de QA. Planificar la importación de órdenes de transportes en una cola de importación. Dominio de transporte Un dominio de transportes consiste de todos los sistemas que planeamos manejar usando el mismo TMS. Dentro de un dominio de transportes, todos los sistemas deben tener un ID de sistema (SID) único y solo uno de estos sistemas es identificado, o mejor dicho tiene el rol, de controlador de dominio (de transportes). El controlador de dominio de transportes es el sistema donde todas las configuraciones de TMS se mantienen. Cualquier cambio en la configuración es distribuida a todos los sistemas en el landscape. Esto asegura que todas las configuraciones de TMS son consistentes a través de todo el dominio. El controlador de dominio almacena la configuración y todos los otros sistemas reciben una copia de esta configuración. Un dominio de transportes contiene al menos un grupo de transportes. Más simple, un grupo de transporte consiste de uno o más sistemas que comparten un directorio de transportes común. Las siguientes figuras muestran la relación entre un dominio de transporte y un grupo de transportes.

Los sistemas dentro de un dominio de transportes se comunican cada uno con otro usando funciones de llamadas remotas (RFC). La comunicación RFC necesita un ID de para acceder a los sistemas destinos. Cuando los sistemas se agregan a un dominio de transportes, los destinos RFC necesarios y los ID de s son automáticamente configurados por la herramienta TMS. La configuración de dominio se distribuye a través del dominio usando la comunicación RFC.

Los cambios en la configuración del dominio de transportes se realizan en el controlador de dominio. Cada vez que hacemos un cambio, una ventana se muestra consultando si los cambios deben ser distribuidos inmediatamente a los sistemas del dominio. Podemos distribuir varios cambios en una sola vez. Estableciendo un Dominio de Transportes Para configurar un dominio de transportes, primero determinaremos cuales sistemas serán incluidos en el dominio. El domino de transportes debería contener todos los sistemas de todos los landscapes de sistemas que serán istrados centralmente mediante TMS. La configuración de TMS puede desglosarse en tres pasos individuales.

1. La configuración del dominio de transportes que define los sistemas que serán incluidos en el dominio. 2. La configuración de las rutas de transportes que define los roles de los sistemas (y clientes) dentro del o los landscapes. 3. La configuración del procedimiento de QA que define quien será responsable para la aprobación y aceptación de cambios y la promoción de los mismos a los sistemas de delivery subsiguientes.

Inicializando el Controlador de Dominio de Transportes El primer sistema que configuramos es automáticamente seleccionado como el controlador de dominio pero más tarde podemos cambiar el rol del controlador de dominio a un sistema diferente.

SAP recomienda que el sistema que seleccionemos para el rol de controlador de dominio tenga los siguientes atributos: Alta disponibilidad Alta seguridad Alto nivel de mantenimiento Por lo tanto, un sistema de producción podría ser ideal para ser el controlador de dominio. Como los sistemas de desarrollo usualmente son instalados antes del sistema de calidad o producción, en la práctica es común configurar el sistema de desarrollo como el controlador de dominio y luego mover la asignación al sistema de producción.

Cuando usamos TMS por primera vez luego de la instalación del sistema, automáticamente nos solicitará configurar TMS. Cuando inicializamos TMS, las siguientes acciones se llevarán a cabo automáticamente por el sistema SAP: Un grupo de transportes es creado con el nombre GROUP_<SID>. En el cliente 000, el de comunicación TMS es creado. Los destinos RFC necesarios para TMS son generados. El archivo de configuración DOMAIN.CFG es almacenado en el subdirectorio bin del directorio de transportes. Este archivo contiene el nombre del dominio de transportes y la descripción así también como el nombre del host de controlador de dominio, número de instancia, SID y grupo de transportes. El perfil de transporte para el programa de control de transportes tp se genera y se almacena en el subdirectorio bin bajo el nombre TP_ .PFL. Los parámetros en este perfil se mantienen usando la transacción STMS. El nombre del domino de transportes no debe contener espacios en blanco y no puede ser modificado después sin reconfigurar el controlador de dominio. Por defecto el dominio de transportes tendrá el nombre DOMAIN_<SID>, donde <SID> es el ID de sistema del controlador de dominio. El programa de control de transportes tp require un perfil de transporte que contenga información sobre cómo establecer la conexión a la base de datos de todos los sistemas SAP en el dominio de transportes. TMS genera y gestiona este perfil de transportes como una parte de la configuración del dominio de transportes. No debemos modificar el perfil de transportes usando un editor de textos en el sistema operativo.

Para visualizar los parámetros de tp en un sistema SAP, llamamos a la transacción STMS. Selecciona Overview Systems. Marca uno de los sistemas y selecciona SAP System Display. Selecciona la solapa Transport tool. Desde el menu, selecciona Goto Display.

Configuración de las Rutas de Transporte y Verificaciones Las rutas de transportes indican el rol de cada sistema y el flujo de las órdenes de transportes. Las rutas de transportes son lo que definen el landscape de sistemas. Aunque TMS ha sido inicializado, no es posible aún realizar transportes hasta que las rutas de transportes hayan sido configuradas y distribuidas. Después de establecer el dominio de transportes, necesitaremos: 1. Modelar las rutas de transportes desde el controlador de dominio, usando: a. Configuraciones estándar (uno, dos o tres sistemas) b. Editor gráfico para configuraciones no estándar 2. Distribuir y activar la nueva configuración para todos los sistemas SAP dentro del dominio de transportes. Para reducir el trabajo para especificar las rutas de transportes, podemos usar las configuraciones estándar. Las rutas de transportes se generan automáticamente cuando seleccionamos los sistemas y la configuración para uno, dos o tres sistemas. Capas y Rutas de Transportes Como mencionamos anteriormente las rutas de transportes definen el flujo de las órdenes de transportes desde un sistema a otro. Estas rutas se denominan de consolidación o de entrega o reparto (delivery).

Una ruta de consolidación es una ruta de exportación/importación. Típicamente, la ruta de consolidación procede desde el sistema de desarrollo (desde donde las órdenes de transportes son exportadas) al sistema de calidad (donde las órdenes de transporte son importadas) en un landscape estándar de tres sistemas. Una ruta de reparto es otra ruta de importación. En el landscape de tres sistemas, la ruta de reparto se especifica entre el sistema de calidad y el sistema de producción porque no hay una exportación desde el sistema de calidad pero si una importación al sistema de producción. El customizing y los objetos de respositorio son asignados a una ruta de consolidación específica mediante una capa de transportes. En el directorio de objetos SAP, el cual es

el catálogo de todos los objetos, están agrupados dentro de unidades lógicas llamadas paquetes, formalmente conocidos como clases de desarrollo. La definición de cada paquete contiene una asignación a una capa de transportes. Los objetos, a través de la asignación del paquete, indirectamente son asignados a la capa de transportes. Todos los objetos entregados por SAP están asignados a la capa de transportes SAP. Todos los objetos de customizing y los objetos de desarrollo que vayan a ser transportados por la ruta de transportes son asignados a otras capas de transportes, estas capas de transportes son normalmente denominadas Z<SID>, donde <SID> corresponde al ID del sistema de desarrollo. En el contexto de las rutas de transporte, un sistema SAP puede tomar los siguientes roles: Sistema de Integración: el sistema donde se originan los cambios y son asignados a las órdenes de transportes. Es el punto donde las modificaciones de “cliente” se integran con el estándar de SAP. Sistema de Consolidación: el sistema destino de una ruta de consolidación. Sistema de Entrega o Reparto: es el o los sistemas destino de una ruta de entrega o reparto.

Necesitaremos configurar más capas de transporte si nuestro landscape es más complejo y también si necesitamos redirigir la ruta de ciertos objetos si no usarán la ruta de transportes estándar. Por ejemplo, si un sistema de entrenamiento separado existe y hay ciertos programas que serán ejecutados allí pero no queremos que esos programas lleguen al sistema de calidad o producción.

Configuración Básica de TMS Ingresar a la tx STMS

Para realizar la configuración del TMS se debe ingresar al cliente 000 en el controlador de dominio y la TX STMS, al no estar configurado el sistema de transporte, se obtendrá una ventana donde solicitara información del sistema donde estamos realizando la configuración y el dominio de transporte que estamos creando para nuestro sistema de transportes ya que para el ejemplo práctico este sería el primer sistema instalado, se tomara los valores propuestos

Una vez que se guarde la configuración, se empezara a trabajar con la tx STMS

Desde esta vista podrá observarse todos los sistemas que integran nuestro dominio de transporte

Para proseguir con la configuración, se creara sistemas virtuales dentro del dominio

Con el sistema virtual podrá configurarse todos los sistemas de transporte sin la necesidad de tener los demás sistemas realmente instalados Se crea el sistema de QAS y PRD

Ya se tiene todo el landsae con los sistemas necesarios

Ahora veremos las rutas de transportes

Pasamos a la visualización del editor grafico

Desde acá se configuraran las rutas de transportes entre los tres sistemas

Arrastramos DEV y luego damos doble clic sobre QAS y PRD para añadirlos en el entorno grafico

Una vez colocado los tres sistemas, empezaremos con la creación de las rutas

Primero se dibuja la ruta que va desde DEV a QAS

La ruta desde un sistema de desarrollo y calidad es de tipo consolidación, este tipo de ruta se otorga a los sistemas desde donde se liberan las órdenes de transporte y el próximo sistema donde se importaran

En la ruta de consolidación también debemos elegir la capa de transporte, por lo general son dos; una capa llamada SAP para los objetos estándar de sap y otra capa llamada ZDEV dependiendo del nombre que tenga el sistema de desarrollo para los objetos propios

Agregamos la ruta de transporte de consolidación con la capa de transporte Z<SID> O ZDEV para todos los objetos que sean creados para en el sistema de desarrollo

Ahora creamos la ruta entre QAS y el sistema de Producción, en este caso es de entrega o Delivery esta ruta se utilizan entre los sistemas en los cuales ambos realicen importaciones de ordenes de transporte

Luego de configurar el sistema de transporte, se guardan los cambios

Otra opción de configurar el sistema de transportes

Sap provee las configuraciones predeterminadas para landscapes de 1,2 o 3 sistemas

En este caso solo se debe indicar cuales son los sistemas de desarrollo, calidad y producción

Luego el sistema generara automáticamente la ruta ente los tres sistemas

Guardar

Lección 1: El Proceso de Transportes Como es del sistema SAP, deberemos asegurarnos el correcto movimiento de cambios a través del landscape de sistemas mediante el curso del proceso de transportes. Pasos en el Proceso de Transportes

Figura 142 – Resumen: Estrategia de Transportes

En las versiones anteriores a 3.1H, los transportes se realizaban a nivel del sistema operativo. Con la introducción del Sistema de Gestión de Transportes (TMS), los transportes se realizan desde el mismo sistema SAP. En el TMS, las órdenes de transportes son transportadas a lo largo de rutas de transportes predefinidas. Ya vimos anteriormente que podemos definir múltiples rutas de consolidación o de entrega. El procedimiento de importación puede ser realizado por cualquier que tenga las autorizaciones desde el sistema SAP sin que se necesite al sistema operativo. Sin embargo, casi todas las funciones en la transacción STMS son ejecutadas por comandos del programa tp en el sistema operativo, que con cierto nivel de conocimiento técnico podríamos llegar a realizar manualmente en algún caso necesario. Las órdenes de transporte que están pendientes de importación se visualizan en la cola de importación del sistema destino desde cualquiera de los sistemas SAP que conforman el dominio de transportes. Usando TMS podemos importar completamente la cola de importación, esto es, todas las órdenes de transporte que fueron exportadas desde el sistema de desarrollo. Esto asegura que ningún error de importación ocurra debido a objetos faltantes y que las últimas versiones de un objeto no sean sobrescritas por versiones anteriores.

Liberación y Exportación

Figura 143 – Proceso de Transporte: Liberación y Exportación

El primer paso en el proceso de transportes es liberar una orden de transporte y por consiguiente exportar todos los objetos asociados desde la base de datos del sistema de desarrollo (DEV) a archivos en el directorio de transportes común a nivel del sistema operativo. Para cada orden de transporte, los datos son exportados a un archivo de datos en el subdirectorio data y un archivo de control es creado en el subdirectorio cofiles. Durante la exportación, las entradas necesarias para la importación siguiente son creadas en el buffer de importación del sistema destino, y una importación de prueba puede realizarse. En el directorio buffer, en el sistema operativo, hay una buffer de importación para cada sistema SAP en el dominio de transportes. El archivo tiene el nombre del sistema SAP al que pertenece (DEV, QAS, PRD, etc.) y contiene información de control respecto a que órdenes de transporte deben ser importadas y en qué orden. Varios comandos de control de transporte pueden utilizarse para manejar los archivos de buffer de importación en el sistema operativo. La información de control en los archivos de buffer de importación es leída y representada como las colas de importación accedidas desde el sistema SAP. Una cola de importación muestra todos las órdenes de transportes que están contenidas en el buffer correspondiente.

Figura 144 – Proceso de Transporte: Importación en QAS

Usando TMS desde el sistema SAP, el segundo paso en el proceso de transportes es: importar todas las órdenes listadas en la cola de importación del sistema de calidad (QAS). TMS realiza la importación iniciando el programa de control de transportes tp en el sistema operativo. Después que las órdenes de transportes se han importado correctamente en el sistema de QAS, las órdenes se agregan en el buffer de importación (con estado inactivas si es que el procedimiento de QA está implementado) y la cola de importación del sistema de producción (PRD) y cualquier otro sistema de entrega según la ruta de transporte.

Figura 145 – Proceso de Transporte: Aseguramiento de Calidad

Después de importar en el sistema de QAS, los objetos necesitan ser testeados por posibles errores. Los errores deben ser corregidos en el sistema de desarrollo, y los cambios importados nuevamente (con una orden de transporte nueva por supuesto) en el sistema de QAS. Durante la importación en QAS, la orden o las órdenes de transportes adicionales son agregadas al buffer de importación del sistema de producción.

Figura 146 – Proceso de Transporte: Importación en PRD

Después que todas las órdenes de transporte que fueron importadas en QAS han sido testeadas y verificadas, las órdenes deben ser aprobadas (si el procedimiento de QA está activo). El estado de la entradas cambian de inactivas a activas y las órdenes de transporte están listas para importar en el sistema PRD.

Usando TMS, podemos importar todas las órdenes de transporte, o simplemente un primer conjunto de las órdenes que fueron verificadas que se encuentran en la cola de importación en la secuencia que se presentan. Para asegurarnos que no haya ningún efecto negativo en las actividades de producción, debemos asegurarnos que los errores y las correcciones se importen en el orden correcto, o sea, respetando el orden de importación de la cola.

Lección 2: Importación usando TMS El de transportes debe seguir las normas establecidas para la estrategia y planificación de transportes. De esta forma, nos aseguraremos que los cambios sean distribuidos de forma consistente en el landscape. Visualizando Órdenes de Transportes usando TMS Las colas de importación de TMS, reflejan los buffer específicos de cada sistema que se encuentran a nivel del sistema operativo. Las colas de importación muestran el orden correcto en que deben importarse las órdenes. Las colas de importación de todos los sistemas se pueden visualizar desde cualquier sistema del dominio de transportes, así también como realizar las importaciones. Para acceder lo hacemos mediante la transacción STMS y luego desde el menú Overview Imports. Allí veremos el estado actual de la cola de importación, a veces es necesario refrescarla para una vista actualizada. El timestamp muestra que tan reciente es la información.

Figura 146 – Información de la Cola de Importación

Para que la información de la cola de importación se refresque automáticamente podemos configurar un job de background periódico. Para esto elegimos STMS Overview Imports Extras Update All Import Queues. Luego seleccionamos con qué período se ejecutará el job. Cada una hora es un tiempo razonable. El programa es RSTMSCOL.

Figura 147 – Colas de Importación y Buffer de Importación

Marca de Stop Los términos buffer de importación y colas de importación están relacionados. La cola de importación en el sistema SAP representa el buffer de importación que se encuentra en el directorio de transportes. La cola de importación resalta las órdenes que serán importadas durante la próxima importación (método importar todo). Debido a la marca de stop (stopmark), podría haber más órdenes de transportes en el buffer de importación que aquellas resaltadas en la cola de importación. El stopmark indica que solo las órdenes anteriores a la marca serán importadas. El stopmark se crea tanto en la cola de importación como en el buffer de importación. En la cola de importación se muestra con la leyenda “End of Import Queue”. En el buffer, el término stopmark se muestra. Puede solo haber un stopmark en cada buffer de importación. Para crear un stopmark para cerrar la cola de importación, desde la misma cola de importación en STMS elegimos Queue Close. Esto es análogo en el sistema operativo con el comando tp setstopmark. Para quitar la marca de stop, aunque normalmente no se realiza esto, desde la misma pantalla selecciona Queue Open. En el sistema operativo tp delstopmark. También podemos mover luego la marca de stop a otra posición en la cola de importación. Seleccionamos la orden delante de la cual queremos situar la marca y elegimos Queue Move End Mark. En el sistema operativo tp mvstopmark.

Figura 148– Cola de Importación

La cola de importación es útil para: Visualizar el estado de las órdenes. Acceder a listas de objetos en las órdenes, documentación, y logs de transportes. Cerrar y abrir la cola y mover la marca de stop. Importar todas las órdenes, proyectos completos, órdenes preliminares, y órdenes seleccionadas de acuerdo a ciertos filtros. Agregar, borrar y redireccionar órdenes. Para mantener los sistemas SAP consistentes, es necesario establecer fechas límites para coordinar la liberación de órdenes de transportes de los desarrolladores. Para prevenir que las órdenes liberadas posteriormente a la fecha límite sean importadas, la cola de importación puede cerrarse. Las órdenes liberadas posterior al cierre de la cola se posicionan luego de la marca de stop en la cola para la próxima importación. Solo las órdenes previas a la marca de stop son importadas. En casos excepcionales, podemos redireccionar una orden de transporte a otro sistema SAP antes de que sea importada en el sistema destino de la cola de importación. Por ejemplo, antes de importarse en el entorno de calidad, una orden necesita ser enviada al sistema de entrenamiento. Para importar una orden en un sistema fuera de la ruta predefinida, en la pantalla de la cola de importación seleccionamos la orden y luego Request Forward System. También podemos borrar o agregar órdenes de transporte a una cola de importación. Las dependencias de objetos pueden causar inconsistencias en el sistema destino luego en la importación. Por ejemplo, si borramos una orden que contiene un nuevo elemento de datos, todas las ordenes que contengan tablas que dependen de ese elemento de dato fallarán. Para evitar estas inconsistencias, es muy importante no borrar órdenes de transporte.

Figura 149 – Importación de Todas las Órdenes de Transporte

Para importar todas las órdenes en la cola, lo que se conoce como un “Importar Todo”, seleccionamos el botón Import All Requests. La ventana Start Import aparece. Si tenemos configurado el Control de Transporte Extendido, el cliente destino está fijado. De otra forma, deberemos seleccionar el cliente destino. Tenemos varias opciones para iniciar el transporte: En la solapa Date podemos planificar la importación. En la solapa Execution podemos seleccionar si TMS iniciará tp de forma sincrónica o asincrónica. De forma asincrónica significa que tp trabajará en background y no bloqueará la sesión durante la importación. En la solapa Options podemos seleccionar opciones expertas conocidas como modos incondicionales. Las opciones y las que son por defecto varían según la estrategia de transportes configurada. La pantalla Import Overview muestra si la importación está corriendo. Después de la importación, la marca de stop es removida y la cola se abre nuevamente automáticamente. Después que las órdenes de transporte han sido importadas exitosamente, son automáticamente agregadas a la cola de importación del siguiente sistema. Si usamos el procedimiento de Aprobación de QA, todas las órdenes en la cola de importación en el o los siguientes sistemas son marcadas como inactivas. Si tratamos de importar órdenes donde al menos una se encuentra inactiva, TMS no realizará la importación. Solamente podremos importar todas las órdenes en un sistema de entrega si todas las órdenes listas para importar han sido verificadas en todos los pasos del procedimiento de aprobación (ya sea que se aprueben o se rechacen). Si todas las órdenes para un proyecto han sido aprobadas, puedes importarlas en el sistema de entrega aún si hay todavía otras órdenes sin procesar por el procedimiento de aprobación o rechazadas en la cola de importación. Si realizamos una importación a través de la opción importar todo, los objetos son importados en la secuencia correcta como se listan en el buffer. Esto significa que si las órdenes de transportes cerca del comienzo de la lista y aquellas cerca del final

afectan a los mismos objetos, las versiones finales de estos objetos después de la importación estarán activos con los últimos cambios. Como resultado, los objetos incorrectos no afectan el ambiente productivo. Podemos desactivar la opción de realizar una importación completa, importar todo, para cada sistema usando el parámetro de TMS NO_IMPORT_ALL

Figura 150 – Importar un Proyecto Completo

Antes de iniciar la importación, SAP recomienda configurar la marca de stop para cerrar la cola de importación. Esto evita la importación de otras órdenes que podrían aparecer en la cola. Podemos usar también filtros en la cola de importación para limitar las órdenes que se muestran con propiedades específicas de forma que podamos ver solo las órdenes que pertenecen a un proyecto particular o con cierta relación entre sí por ejemplo porque fueron creadas por el mismo . Para configurar un filtro, debemos posicionar el cursor en una columna de la cola de importación y seleccionar el botón Filters.

Figura 151– Importar una Única Orden de Transporte (Importación Preliminar)

En contraste a las importaciones estándar, las importaciones preliminares son importaciones de una única orden (o un conjunto seleccionado). SAP recomienda

utilizar la importación estándar por la dependencia entre objetos y el riesgo de inconsistencias cuando se importan órdenes individuales. Por ejemplo, un reporte ABAP en una orden puede ser importado correctamente, pero la tabla a la que refiere puede estar en otra orden de transporte que no ha sido importada aún. Hasta que la tabla no es importada, la ejecución del reporte generará short dumps. Por esto debemos usar la importación preliminar en casos excepcionales. Para minimizar los riesgos asociados con importaciones preliminares, la orden queda en la cola de importación luego de que ha sido importada y es re-importada la próxima vez que toda la cola es importada. Esto garantiza que la secuencia de exportación e importación es siempre la misma. Esto se define con la opción Leave Transport Request in queue for later import, la cual es marcada dependiendo de la estrategia de transportes.

Lección 3: Opciones y Estrategias de Transportes Opciones Adicionales en la Importación En circunstancias particulares, podría ser necesario especificar opciones adicionales cuando realizamos una importación preliminar. Ignorar que la orden de transporte ya ha sido importada. Sobrescribir originales: si un objeto fue creado en el sistema destino y la orden contiene el mismo objeto tendremos que usar esta opción para que la importación no falle. Sobrescribir objetos en reparaciones sin confirmar: un objeto que fue modificado en un sistema donde no es original, por ejemplo un objeto estándar de SAP, es un objeto marcado como reparado en el sistema. Si la orden contiene un objeto que en el sistema destino está marcado como reparado, deberemos utilizar esta opción. Ignorar tipo de transporte inválido Los objetos de las órdenes de transportes seleccionadas para importación serán importadas de la siguiente manera: Todos los objetos de todas las órdenes de transportes son tratados de manera conjunta, esto es, independiente de la orden a la que pertenecen. Primero todos los objetos son ordenados de acuerdo al nivel que pertenecen (ej. las definiciones de tablas antes que los programas). En caso de un objeto que se encuentra en más de una orden de transporte, solo la versión en la última orden de transporte es importada (de acuerdo a la secuencia en la cola de importación) Esto es independiente del método de importación elegido (Importar Todo, Importar Proyecto, Importación Individual)

En un landscape de tres sistemas, la cola de importación de QAS refleja el orden de exportación de DEV. La cola de importación de PRD refleja el orden de importación que se realizó en QAS. Esto no siempre es idéntico en todos los casos. Pero es la secuencia correcta.

Planificación de Importación

Figura 152 – Fecha y Hora de Importación

Dependiendo si seleccionamos la importación por proyecto, importación individual, importar todo, o un workflow especial de transporte y particularmente de la versión de SAP y nivel de Package, las opciones pueden variar. Cuando iniciamos una importación, podemos elegir las siguientes opciones en la solapa Date: Immediate Seleccionando esta opción inmediatamente inicia la importación en un work process de diálogo.

At Start Time Si elegimos esta opción la importación inicia en una fecha y hora específica. Se planifica un job de background en el sistema destino. Si ingresamos un fecha y hora en el campo No Start After, la importación puede iniciar en la ventana de tiempo entre Planned Start y No Start After. Si no hay work processes de background disponibles durante la ventana de tiempo, la importación no se relaliza. Si queremos que la importación se realice regularmente debemos ingresar la frecuencia en el campo Period. After Event Seleccionando esta opción la importación se inicia solamente después que un evento específico se dispare. Si seleccionamos Execute Import Periodically, la importación se inicia cada vez que el evento seleccionado ocurre. De otra manera, la importación ocurre solo la primera vez que sucede el evento.

En los transportes individuales o en un workflow de transporte el campo Period no existe. Desde la cola de importación de cada sistema SAP, podemos monitorear y mantener todas las importaciones planificadas seleccionando Goto Job Monitor.

Figura 153 – Frecuencia de Transportes

Después de la exportación, una orden de transporte no es importada automáticamente, sino que debe hacerse manualmente. Cuando planificamos las importaciones, deberíamos incluir un tiempo suficiente entre cada importación para poder realizar las tareas de pos-importación tal como las pruebas de QA. SAP recomienda que la planificación de las importaciones sea intervalos de tiempo regulares tal como mensual, semanal o diaria y usando la estrategia Importar Todo en el sistema destino. La importación frecuente no es recomendada. Las siguientes acciones tienen que considerarse: Liberación de órdenes de transportas. Copia en un cliente en el mismo sistema (de desarrollo) mediante la transacción SCC1 (test unitario). Importación en clientes en sistemas subsiguientes. La frecuencia de transportes está basada en los siguientes factores: Clientes y los roles de estos en el landscape de sistemas. Requerimientos de sincronización, esto es, cuando son requeridos los cambios en los diferentes sistemas. Requerimientos de Congelamiento de Código (Code Freezing). Estrategias de Transportes Hay tres estrategias de transportes diferentes disponibles: Transporte masivo controlado por la cola. Transporte individual controlado por la cola. Transporte controlado por workflow.

La estrategia de transporte es por defecto el Transporte masivo (Importar Todo). Transportes Masivos: son una buena solución si tenemos que sitrar un gran número de transportes y queremos automatizar el proceso lo más que podamos. El uso continuo de importación masiva es la forma más segura de mantener los sistemas sincronizados y consistentes. Antes de importar con este método en el sistema de producción, deberemos verificar que todas las órdenes en el sistema de calidad y la confirmación (o aprobación) de estas en los demás sistemas (por ejemplo el de producción). Para esto usamos el procedimiento de QA en TMS. También deberemos definir la importación masiva como el método elegido para los sistemas relevantes. Para esto, seleccionamos la estrategia de transportes Queue-controlled mass imports. El puede planificar las importaciones periódicamente en TMS, o iniciar cada importación manualmente. Solamente deberíamos importar órdenes individuales antes que otras según el orden de la cola de importación en casos especiales. Las órdenes de transportes que son importadas previamente son importadas nuevamente en la importación normal, o sea la importación masiva. Esto es así por la opción Leave transport request in queue for later import la cual se selecciona automáticamente cuando realizamos un transporte que no sea masivo (Importar Todo). También podemos usar workflow para importar órdenes de transportes individuales. Importación Individual: usamos esta estrategia si tenemos pocos cambios para transportar y la organización no nos permite realizar una planificación fija de transportes. Este método usualmente demanda un esfuerzo extra para los es en comparación a los transportes periódicos. Los desarrolladores deberán poner atención a la consistencia de sus órdenes de transportes. Si un número pequeño de desarrolladores están trabajando en un proyecto, y también en un mismo equipo con el , usualmente crean sus propias órdenes de transporte e incluso la importación de las mismas en el sistema de calidad. En el caso en que los transportes individuales que realicemos en el sistema tengan que realizarse por el de sistema, recomendamos que se utilice el workflow de transportes. Este método automáticamente dispara un workflow cuando se libera la orden de transporte. El workflow asegura la comunicación entre el desarrollador y el . Como requisito tendremos que haber configurado el worfklow de transportes en el sistema.

Lección 4: Establecer y Modificar Estrategias de Transportes Mantener las Estrategias de Transporte La estrategia de transporte masivo está configurada por defecto en el sistema luego de la instalación y configuración de TMS. Si queremos trabajar con transportes individuales controlados por cola o transportes controlados por workflow, podremos seguir los pasos de configuración descriptos a continuación:

Figura 154 – Transacción STMS: Overview → Transport Routes

Inicia la transacción STMS y luego Overview ->Transport Routes. La pantalla Display ->Transport Routes aparece mostrando las rutas de transportes existentes en 1.

el dominios de transportes. 2.

Cambia al modo de edición seleccionando Configuration ->Display ↔ Change.

3. Posiciona el cursor sobre el sistema SAP para el cual queremos cambiar la configuración de la estrategia de transportes. 4. Seleccionamos Edit ->System ->Change. El cuadro Change System Attributes aparece. 5. Seleccionamos la solapa System Attributes y luego elegimos la estrategia de transportes. Dentro de un grupo de transportes debemos configurar a todos los sistemas con la misma estrategia, ya sea Queue-controlled transports o Workflow-controlled transports. 6. Seleccionamos Copy. 7. Luego Configuration

Distribute and activate.

Configuraciones en TMS dependiendo de la Estrategia de Transporte Queue-controlled mass transports (Transportes masivos controlado por cola) Por defecto la opción Leave transport request in queue for later import está activada, cuando se realiza una importación individual. La opción de importación Leave transport request in queue for later import hace que las órdenes importadas como transportes individuales se mantengan en la cola de importación para que sean importadas en el orden correcto en la próxima importación de todas las órdenes. Esta opción es útil si tenemos que hacer una importación preliminar para órdenes individuales. Esto previene que objetos más antiguos sean importados en la próxima importación normal de todas las órdenes. Queue-controlled single transports (Transportes individuales controlado por cola) Por defecto, la opción de importación Leave transport request in queue for later import está desactivado. La barra de botones en la cola de importación cambia de acuerdo a los requisitos de la estrategia de importación de transportes individuales. Por ejemplo, contiene una función de selección. En la función Importar Todo (el camión con carga completa) está solamente disponible si elegimos uno o más proyectos usando la función de filtro. Esto previene que se importe accidentalmente todas las órdenes en la cola. Workflow-controlled transports (Transportes controlados por workflow) Las propuestas de transportes son creadas automáticamente cuando las órdenes son exportadas. Las opciones de importación se corresponden con las de los transportes individuales. Las importaciones se agregan a la lista de procesamiento de las propuestas de transportes en la lista de trabajo de TMS. Una advertencia aparece en la cola de importación si intentamos realizar transportes sin usar el workflow de transportes. Los siguientes parámetros para el programa de control de transportes y el Sistema de Cambios y Transportes (CTS) son configurados acorde a la estrategia de transportes elegida: Parámetros de tp para las estrategias de transportes:

El parámetro de tp STOPONERROR define a partir de que código de error la importación se detiene. REPEATONERROR define desde que código de error la importación no es clasificada como exitosa y tiene que repetirse. Por ejemplo, con Transportes Individuales, el código de error 8 es tomado como una importación fallida y tiene que ser repetida. Con Transportes Masivos, el mismo código de error 8 será una importación exitosa. No cambies manualmente los parámetros que son relevantes a la estrategia de transportes. TMS genera estos parámetros cada vez que la configuración de rutas de transportes es modificada. Transportes de Copias y Reubicación

Figura 155 – Transporte de Copias y Reubicación

Utiliza la función Transport of copies para transportar objetos a otro sistema SAP que seleccionemos. Esta función es especialmente útil si el sistema destino no es un sistema de consolidación desde el sistema donde vamos a generar la orden. Los objetos son transportados con la versión que tienen en el sistema donde nos encontramos. La ubicación original del objeto (sistema origen) no es modificada. La orden de transporte no será agregada tampoco a la cola de importación de un sistema subsiguiente en la ruta de transportes.

La función Relocation of objects w/o package change nos sirve si el trabajo de desarrollo sobre los objetos se realizará temporalmente en otro sistema SAP. Algunos desarrollos especiales podrían ser realizados en un sistema SAP separado, por ejemplo, para no interferir con el proceso normal de desarrollo. Estos tipos de órdenes nos permite mover ubicaciones originales de los objetos a un sistema destino, o sea cambiar el sistema al que pertenece donde es original el objeto. Usamos la función Relocations of objects with package change cuando el sistema de desarrollo de los objetos que transportaremos será cambiado de manera permanente. Este tipo de órdenes nos permite cambiar la ubicación original de los objetos al sistema destino y también cambiar el paquete de los objetos al mismo tiempo. Debido a esto último, los objetos tienen los atributos del paquete al que son asignados en el sistema destino inmediatamente luego de la importación. Usamos Relocations of Complete Package cuando el sistema de desarrollo de un paquete completo será cambiado de manera permanente.

Lección 5: Configuración y Características del Procedimiento de QA Las órdenes de transportes serán importadas en el sistema de producción solamente después que sean aprobadas en el sistema de calidad. Por lo tanto necesitaremos contar con un procedimiento de aprobación de calidad. Aseguramiento de Calidad en TMS El procedimiento de aseguramiento de calidad (QA) incrementa la calidad y la disponibilidad del sistema de producción permitiéndonos verificar las órdenes de transporte en el sistema de calidad antes de que sean entregadas en los sistemas subsiguientes. Cuando activamos el procedimiento de aprobación de calidad QA, las órdenes de transporte estarán disponibles para ser importadas en el o los sistemas de entrega si todos los pasos del proceso de calidad han sido aprobados. Cuando configuramos el sistema de QA determinamos cuantos pasos de QA deberán aprobarse para cada orden de transporte. Si uno de los pasos no es aprobado, entonces la orden no puede ser aprobada. Solo podremos importar órdenes que hayan sido completamente aprobadas. Las órdenes rechazadas no son importadas en el sistema de entrega.

Figura 156 – Configuración del Procedimiento de Aprobación de QA

Antes que podamos procesar órdenes de transportes deberemos configurar el procedimiento de aprobación de QA. Al menos deberemos contar con un landscape tradicional de tres sistemas (DEV, QAS y PRD). El sistema que que configuremos como el sistema QA deberá contar con los siguientes atributos: Debe ser el destino de al menos una ruta de consolidación. Debe tener una ruta de entrega hacia otro sistema al menos. Después de la configuración, la lista de trabajo de QA es automáticamente creada. Todas las órdenes importadas en el sistema de QA son incluidas en la lista de trabajo de QA. Pasos en el Procedimiento de Aprobación de QA Para visualizar la lista de trabajo de QA, usamos las transacción STMS y seleccionamos Overview Imports Goto QA worklist. La fecha y hora en la parte superior derecha de la pantalla indica cuando la lista de trabajo de QA ha sido actualizada por última vez; la parte susperior izquierda indica cuantas órdenes aún están pendientes de procesamiento. La lista muestra las órdenes de transporte que se corresponden con el paso de aprobación seleccionado. Por defecto, las órdenes correspondientes a todos los pasos se visualizan en primer lugar. Para seleccionar el paso de aprobación y ver todas las órdenes que concuerdan con el mismo seleccionamos Worklist Select Approval Step. Con un doble clic sobre uno de los ítems en la lista de trabajo podemos obtener más detalles sobre el mismo.

Figura 157 – Aprobación QA

Antes de importar las órdenes en un sistema de entrega deberíamos testear las órdenes en el sistema de QA. El estado de QA rechazada (rejected) siginifica que uno o más pasos de aprobación no fueron aprobados por la persona responsable. Una orden es aprobada solamente si todos los pasos de aprobación tienen el estado aprobado (approved). En la lista de trabajo de QA podemos ver: El estado de QA (St) El estado general (GS) El número de paso (Nr) Una vez que todos los pasos de aprobación fueron procesados satisfactoriamente entonces la orden de transporte podrá ser importada en el sistema de entrega. Si todas las órdenes para un proyecto han sido aprobadas, pueden ser importadas en el sistema de entrega a pesar que otros proyectos aún tengan órdenes pendientes de procesar o rechazadas en la lista de trabajo de QA. Las órdenes con el estado rechazada en QA así también como las órdenes aún sin procesar en la lista de trabajo no son importadas en los sistemas de entrega. A partir de la versión 6.10 la aprobación o rechazo de un paso individual puede ser modificado, mientras que el procedimiento completo de aprobación no esté realizado. Una vez que todos los pasos de aprobación están completo, no es posible cambiar la decisión. SAP recomienda no rechazar las órdenes que contengan errores, sino más bien corregir los errores en una nueva orden de transporte y luego aprobar todas las órdenes de transportes vinculadas en conjunto.

Figura 158 – Historial de QA

Desde la pantalla de la lista de trabajo de QA, podemos acceder al historial de QA mediante Goto QA History. El historial de QA muestra todas las órdenes para un período específico que ya no se muestra en la lista de trabajo. Las órdenes no se visualizan tampoco en la lista de trabajo una vez que han sido aprobadas o borradas. El período por defecto para la lista de QA es de 30 días pero puede ser cambiado. Para determinar quien fue responsable de aprobar una orden de transporte, seleccionamos Request Display QA Status El historial de QA se almacena en la base de datos del sistema de calidad, por lo que si realizamos una copia de base de datos o de sistema desde el sistema de producción por ejemplo, el historial se perderá. Podemos consultar por notas en el Marketplace de SAP para mayor información.

Workflow de Transportes Especiales

Figura 159 – Workflow de Transportes Especiales

Utilizaremos el workflow de transportes si se requieren de manera urgente un transporte de correcciones o si se necesitan transportes que no siguen la ruta de transportes definida. Antes de utilizar el workflow de transportes, será necesario configurar uno de los sistemas como el Workflow Engine. Este sistema debería tener las siguientes características listadas en orden de importancia: Alta disponibilidad Carga de trabajo baja a media Estos requisitos son por ejemplo los que posee el sistema de calidad QAS. Todas las tareas realizadas por el workflow de transportes son centralizadas en el Workflow Engine y luego los resultados se comunican a los sistemas SAP involucrados.

Figura 160 – Configurando el Workflow de Transportes Especiales

Para configurar el workflow de transportes especiales, realizaremos lo siguiente: Ingresamos al sistema que funciona como controlador de dominio de transportes. Iniciamos la transacción STMS y luego desde el menú Overview Systems Goto Transport Domain. Seleccionamos la solapa Worfklow Engine. Cambiamos al modo de edición con el botón de Display ↔ Change. Ingresamos el sistema SAP, el cliente y el host destino para el Workflow Engine. Luego de guardar las modificaciones tendremos que aceptar afirmativamente el cuadro para distribuir la configuración. A continuación ingresamos al sistema que funcionará como el Workflow Engine. El sistema automáticamente: Crea el TMS_WF. Genera los destinos RFC necesarios para el Workflow Engine. Envía los datos propios de Workflow Engine a todos los sistemas en el dominio de transportes. Realiza el customizing para el worfklow en el sistema.

Figura 161 – Creando las Propuestas de Transportes

Para utilizar el workflow de transportes, tendremos que crear una propuesta de transportes. Para esto, desde el Organizador de Transportes, transacción SE09 y seleccionamos las órdenes liberadas (released requests). Seleccionamos la orden de transporte que vamos a transportar y luego seleccionamos Utilities Create Transport Proposal. Una ventana aparece donde ingresamos una descripción y el sistema destino, y también podremos agregar otras órdenes de transporte. La condición es que todas las órdenes que ingresemos en la propuesta de transporte estén liberadas. Si una propuesta de transporte es creada, el sistema SAP le asigna un número de propuesta y luego es agregada a la lista de trabajo de TMS para el de transportes. Si el de transportes rechaza la propuesta de transporte aparecerá nuevamente en la bandeja de entrada de propuestas de transportes del solicitante. Podremos cancelar la propuesta o revisarla y reenviarla nuevamente al de transportes. Después que el de transportes ha aprobado la propuesta, la importación se inicia y la propuesta de transportes reaparece en la bandeja de entrada del solicitante. Luego de que verificamos que la orden de transporte se importó correctamente en el sistema destino, confirmamos la propuesta de transporte.

Figura 162 – Lista de Trabajo de Propuestas de Transportes

Para aprobar o rechazar una propuesta de transportes, iniciamos la transacción STMS. Para visualizar la lista de trabajo de TMS, seleccionamos Overview Worklist. Con doble clic seleccionamos la propuesta de transporte que queremos procesar. Podremos verificar allí si las órdenes, la lista de sistemas destinos, las fechas de importación y opciones para la propuesta de transportes son correctas. También podemos visualizar las órdenes de transporte seleccionando Display y el ícono de los logs de transportes. Cambiamos al modo de modificación si queremos hacer modificaciones a las órdenes de transportes, destinos, fecha de importación u opciones de importación. Se pueden agregar mensajes para un desarrollador por ejemplo con el ícono Manage Attachments. Para procesar la propuesta de transporte, seleccionamos el ícono para aprobar o rechazar la propuesta. Una vez aprobada una propuesta de transporte, la importación en el o los sistemas destinos es iniciada automáticamente.

Tutorial Sap 5z4t1u

Overview 26281t

More details 6y5l6z

Related Documents 3h463d

Tutorial Sap 5z4t1u

Tutorial Sap 5z4t1u

Sap 2000 Sap 2000 Tutorial 5ej2l

Sap Design Studio Tutorial k226s

Sap C4c Tutorial 3n3x52

Sap Simple Logistics Tutorial 3l3b6s

More Documents from "David Montoya Morales" 44s60

Tutorial Sap 5z4t1u

Tipos De Plataformas Offshore r4172

Muestreo De Fluidos De Yacimiento 191q73

Termo 4 - Comportamiento De Fases (sustancias Puras) 711y2u

Preguntas Repaso Cap 3 Economia 2zm40

Monitoreo I Biocity Final Urna 4tl1e