Tag: SAP Netweaver
A Menudo los clientes nos preguntan sobre la gestión de documentos en SAP, ya que la palabra «documento» se utiliza en muchos contextos dentro del entorno SAP y en ocasiones puede llevar a confusión acerca de lo que significa la gestión de documentos (DMS) en SAP.
En el contexto de las funciones de la aplicación central SAP ECC, la gestión de documentos es la vinculación de archivos, llamados originales, a los objetos de SAP. Los archivos originales pueden ser casi cualquier archivo electrónico, incluyendo hojas de cálculo, archivos de procesadores de texto, mapas de bits, archivos CAD, documentos escaneados, o archivos de programas, incluso programas especializados, como programas de control de planta. El único requisito previo es que el equipo que se utiliza para acceder al original tenga instalada alguna aplicación que pueda visualizar ó modificar el original. Esto puede incluir incluso aplicaciones de red, si se ha realizado la correspondiente configuración.
A través de la utilización del Document Information Record, muchos objetos en SAP pueden tener originales vinculados y acceder a ellos. Ejemplos de objetos SAP que pueden llevar documentos vinculados son los siguientes:
- Maestro de Materiales.
- Ubicaciones y equipos
- Maestro de clientes.
- Maestro de empleados.
- Clasificación y características
Con la configuración adecuada, el sistema permite no sólo adjuntar un archivo a los datos maestros, sino también a los datos transaccionales donde dichos datos maestros se utilizan, tales como:
- Órdenes de Producción
- Ordenes de mantenimiento
- Elementos PEP
- Facturas
- Pedidos de compra
- Lotes de inspección
En algunos casos los originales están almacenados en otro sistema de gestión documental, pero la mayoría de los sistemas de gestión documental de primer nivel tienen interfaces con el sistema SAP que permiten acceder a los originales de forma perfectamente integrada desde el sistema SAP.
Hablando del repositorio, debido a la posibilidad de archivos muy grandes, el mismo no se gestiona directamente en la base de datos de SAP sino en un sistema separado. Esto podría realizarse en forma de servidores de red, en unidades especializadas como repositorios CAD o en los ya mencionados sistemas de gestión documental de terceros.
DMS permite el control de versiones y la gestión de autorizaciones de seguridad, así como la vinculación de varios originales a varios objetos de SAP de forma simultánea. DMS también es el único método para interconectar con sistemas DMS de terceros.
Y, por último, un breve comentario sobre Easy DMS. Easy DMS es un front end para instalar en PC’s cliente y que básicamente tiene la misma funcionalidad que la transacción de Document Info Record (DIR). Este front end está pensado para el usuario ocasional de SAP que sólo necesita para crear, modificar o visualizar DIR y los originales vinculados a ellos. Por ejemplo, alguien en el departamento de recepción puede ser responsable de la digitalización de los documentos que se reciben y de anexarlos al pedido de compra de SAP. Mediante esta interfaz puede realizar este trabajo de una forma sencilla.
La rapidez con la que SAP evoluciona sus productos hace que, en ocasiones, exista una cierta confusión en cuanto a la nomenclatura de los diferentes productos y sus respectivas plataformas SAP Netweaver.
Por este motivo, es a veces difícil identificar cuál es la Plataforma Netweaver utilizada en las diferentes suites SAP: SAP Business suite 7, SAP Business suite 7 Innovations 2010 y SAP Business suite 7 Innovaciones 2011, EHP5, EHP6, BW / EP / IP EHP 7.3, etc.
Con el fin de arrojar un poco de luz al respecto, y sabiendo que entender correctamente estos aspectos sin duda ayuda a nuestros clientes y a sus administradores SAP a realizar tareas como la instalación, actualización, y mantenimiento de sus sistemas, ofrecemos a continuación un resumen de productos SAP que se ejecutan en la plataforma SAP NetWeaver 7 EHP1, 2 y 3.
A menudo, los clientes de SAP se enfrentan con problemas de rendimiento y no hay requisitos para ajustar los sistemas SAP. En estas ocasiones, se vuelve muy importante establecer los parámetros de la memoria a los valores óptimos de SAP a fin de que cualquier servidor SAP tenga un buen rendimiento. Aún más importante es entender el concepto de gestión de memoria en el servidor de aplicaciones SAP antes de hacer cualquier cambio en los parámetros.
Así que vamos a echar un vistazo rápido a algunos de los conceptos de gestión de memoria en la pila de ABAP. Mediante el sistema de gestión de memoria SAP asigna memoria a cada proceso de trabajo. Existen los siguientes tipos de memorias en SAP:
- Roll memory.
- Extended memory.
- Private memory.
1. Roll memory.
La memoria inicial asignada a un contexto de usuario es la roll memory. De nuevo es asignada en caso de que la extended memory esté llena. El rol area es un área de memoria que tiene un tamaño configurable para cada proceso de trabajo y se encuentra en el “heap” de espacio de direcciones virtuales del proceso de trabajo.
Cuando el contexto de un proceso de trabajo cambia, los datos se copian del área de la memoria al fichero. Para evitar la copia repetida, se coloca otro búfer en el medio, el cual forma parte de la memoria compartida.
El área de despliegue consiste en dos segmentos:
- ztta / roll_first : se le asigna al proceso de trabajo por primera vez como memoria.
- ztta / roll_area : Si ztta / rool_first se utiliza por completo, la diferencia entre ztta / roll_area y ztta / roll_first se le asigna también al proceso de trabajo.
2. Extended memory.
Los procesos de trabajo en SAP tienen una parte reservada en su espacio de direcciones virtuales de la extended memory. El tamaño se puede ajustar utilizando el parámetro de perfil em / initial_size_MB: Tamaño del pool de extended memory.
En la extended memory se pueden mapear desde los recursos comunes hasta cualquier proceso de trabajo. También se puede utilizar el espacio de direcciones virtuales. La extended memory varía con el sistema operativo y por lo tanto puede ser implementada según las necesidades.
En el caso de Windows es automáticamente gestionada. El sistema SAP crea una capa dentro de las funciones del sistema operativo para la gestión de páginas de esta memoria. La extended memory se implementa como un archivo mapeado sin nombre. Esto significa que el espacio de direcciones utiliza el archivo de paginación o usa el swap del sistema operativo como background memory.
3. Private memory.
Si un proceso de trabajo de diálogo se ha agotado el área rol asignado al mismo y también la extended memory, private memory se le asigna al proceso de trabajo. El proceso de trabajo entra en el modo PRIV (privado).
Esta memoria está dedicada a un proceso por lo tanto un proceso de trabajo se puede ejecutar en modo PRIV también llamado el modo privado, cuando la memoria local se agota. Otros procesos no pueden utilizar la prívate memory.
Después de liberar la memoria asignada, el sistema operativo sigue considerando que la memoria virtual que está ocupada por el proceso de asignación.
Estas características de la pila de memoria requieren que:
- El proceso de trabajo se puede ejecutar en modo PRIV cuando la memoria local está asignada y significa que el proceso de trabajo está reservado para el procesamiento del contexto del usuario actual hasta que el contexto libera el proceso de trabajo de nuevo cuando la solicitud haya terminado.
- El proceso de trabajo, si se ha utilizado una gran cantidad de prívate memory, se reinicia cuando el contexto de usuario se termina y la memoria local se devuelve. El reinicio hace que la memoria local vuelva a estar disponible para otros procesos. El reinicio se produce cuando un proceso de trabajo utiliza más memoria local de la que se define en el parámetro abap / heaplimit.
En el caso de que muchos procesos de trabajo entren en el modo PRIV, podría causar graves problemas de rendimiento en el sistema.
El parámetro de perfil rdisp / wppriv_max_no define que en el modo PRIV, un número máximo de procesos de trabajo de diálogo se pueden ejecutar sin restricciones de tiempo.
En plena fase de expansión BLANCO ha planteado a ASPA el reto de dotar a la compañía de una solución de análisis de la información que le ayudara a la toma de decisiones estratégicas y definición de objetivos para todos y cada uno de los niveles y departamentos de la organización.
La solución se basará en SAP Netweaver Business Intelligence e integrará información relevante para la toma de decisiones desde todas las áreas de la empresa.
Sobre BLANCO
Blanco es una multinacional española, que se dedica al diseño, la fabricación y la comercialización de todo tipo de accesorios y prendas de vestir para la mujer joven y para el hombre joven y urbano. La empresa ofrece las últimas tendencias en moda en sus propios puntos de venta.
La cadena se compone, a fecha de hoy, de más de 150 tiendas, entre España, Portugal, Reino Unido y Arabia Saudí, todas ellas ubicadas en las principales áreas de las ciudades más importantes y en los centros comerciales más prestigiosos. Cuentan además con casi 2.000 empleados entre los equipos de tienda y las personas que trabajan en la sede central y la plataforma logística.
Además de crear un producto propio, su objetivo es ofrecer moda a sus clientes y hacer de la compra una experiencia placentera. Se dirigen a un público joven y urbano que exige moda y calidad a precios razonables.
Los clientes que deseen actualizar a SAP ERP 6.0 y se están ejecutando SAP R / 3 con tecnología de software MDMP deben combinar su actualización con una conversión de Unicode. Las anteriores tecnologías de SAP se han vuelto obsoletas por varias razones (por ejemplo, no permiten una adecuada comunicación con aplicaciones basadas en Java.)
Una conversión Unicode sólo es necesaria para aquellos que utilizan páginas de códigos MDMP. Algunas organizaciones, si lo desean, puede realizar una conversión de Unicode para proporcionar apoyo en el futuro de las lenguas con las páginas de códigos diferentes (por ejemplo, para los usuarios en países de Asia o del este de Europa). Convertir o no convertir depende de varios factores. El siguiente gráfico muestra las rutas de actualización recomendada para la conversión de Unicode:
Nota importante: Si va a convertir a Unicode en la puesta en productivo de un proyecto de actualización (es decir, un cambio de versión ó upgrade), debe tener en cuenta otros requisitos de tamaño, tales como los descritos en las notas de SAP dedicadas al tema de la conversión a Unicode que puede encontrar.
Para fines distintos (para lanzar una alerta, para realizar un seguimiento de modificación, para el seguimiento de los documentos, para recuperar valores de los parámetros antiguos después de un error, etc.), a veces es necesario buscar el historial del documento.
¿A que nos referimos con documento? Esta es la terminología de SAP que puede significar en nuestro contexto, el maestro de materiales, el pedido de compra, el recorrido del material, la cuenta de GL, el activo, el centro de trabajo, etc. Así que tanto los datos maestros como los datos transaccionales, se pueden trazar si el sistema SAP en cuestión está adecuadamente parametrizado.
Básicamente, existen dos tablas principales (no lo suficientemente bien conocidas), a las que se puede acceder a través de ABAP o módulos de función.
Estas dos tablas son, la tabla CDHDR (Cabecera documentos de modificación) y CDPOS (Posición documentos de modificación). En el módulo HR las tablas son: PCDHDR y PCDPOS).
Que se pueden leer con un ‘Select’ si se utiliza un programa a medida o mediante el uso de, respectivamente, de los siguientes módulos de función:
«CHANGEDOCUMENT_READ_HEADERS ‘
«CHANGEDOCUMENT_READ_POSITIONS ‘
Como estas tablas registran las modificaciones que se realizan en SAP, podemos imaginar el tamaño de ellas, en especial la CDPOS. Y, por desgracia, como se trata de una tabla cluster, no se puede utilizar una join query.
Y este es el principal inconveniente. Al utilizarlas hay que tener mucho cuidado en la construcción de la consulta, llenando todos los campos clave que se puedan.
No hay muchas historias de éxito o de fracaso de SOA a compartir ya que pocos realmente han logrado completar la adopción de SOA, pero hay muchas empresas que han comenzado su viaje en ese campo. Como parte de mi trabajo tengo la oportunidad de formar parte de varios viajes de SOA y aunque están en las primeras etapas ya hay varias lecciones que hemos aprendido.
En todos los contratos SOA en los que yo estaba involucrado, nos dimos cuenta (tarde o temprano, y cuanto antes mejor) que sin tres pilares principales del edificio que estamos tratando de construir se derrumbaría. Estos principios son: el apoyo e implicación CxO, la semántica y un modelo de propiedad de la información clara.
Apoyo e implicación CxO:
SOA no es sólo una tecnología o la arquitectura de IT, SOA es un cambio que afecta a toda la empresa. La adopción de SOA afecta el dominio del negocio de la empresa, así como los dominios de la información, aplicaciones y tecnología. Refleja las necesidades del negocio. Por lo tanto, si la empresa no adopta los servicios como un concepto para dirigir la empresa, la implantación de SOA será un fracaso. Los cambios en el negocio demandan no sólo apoyo sino también la participación de CxO en este proceso. Sin el apoyo y la participación directa del nivel de CxO no conviene ni siquiera tratar de iniciar al viaje SOA.
Semántica:
La semántica es esencial para SOA. Sin semántica de negocio e información, será imposible crear una implementación de SOA. Si su empresa no tiene ningún modelo semántico de negocio ni de información usted no tiene los fundamentos para crear servicios que proporcionan las funciones de negocio mediante el uso de la información como las entradas y salidas. Usted sólo tendrá las bases para construir otra torre de Babel. La creación de modelos semánticos puede parecer obvia y sencilla, pero la mayoría de las empresas no tienen un modelo semántico para los negocios y la información de que (al menos) la mayoría de las unidades de negocio de la empresa aceptan. Además, es un proceso complejo y tedioso para construir modelos semánticos y el apoyo a su alrededor. Creo que sin un marco o metodología probada esta tarea se hace aún más difícil de lograr. Sin un modelo semántico claro se encontrará en un callejón sin salida de una forma u otra.
Modelo de propiedad de la información clara:
La información es el componente central de SOA. Al final del día los servicios de negocio reflejan las capacidades de manipulación de datos. La mayoría de los problemas de IT en la empresa, por lo general, provienen de situaciones donde la información es manejada por dos o más unidades de negocio o es sólo un activo de una unidad de negocio. Si queremos construir una verdadera implementación de SOA, la propiedad de la información debe ser explícita y aprobada por todas las partes en la empresa. Los servicios se refieren a la manipulación de datos y la transferencia de los resultados para evitar silos de datos y la duplicación de datos. Sin acuerdos sobre la propiedad de la información no seremos capaces de solucionar los problemas. Por lo tanto, los problemas van a aflorar a la superficie en el transcurso de nuestro trabajo.
Uno de los pasos más importantes en un proyecto de movilidad es la selección de los dispositivos con los que los usuarios finales trabajarán todos los días, y que el administrador de sistemas tendrá que administrar.
Realmente, nunca hay un dispositivo perfecto para un caso determinado. La razón es que la selección del dispositivo es siempre un compromiso entre todas las partes involucradas en su selección, y no todas las partes estarán completamente satisfechas con la elección que se realice porque sus intereses son en algunos casos contrapuestos:
- Los usuarios finales por lo general prefieren los dispositivos pequeños y rápidos. Además los dispositivos deben ser lo más robustos posible, pero sin ser demasiado pesados. Y, por supuesto, la batería debe durar mucho. Y no olvidemos que la pantalla debe ser tan grande como sea posible, aunque el dispositivo sea pequeño. Es fácil ver adonde conducen estos requerimientos: muchos de ellos con contradictorios y, si encontráramos un dispositivo que los cumpliera en su mayor parte, sería sin duda muy caro.
- Esto último es algo que a la dirección de la compañía, que tiene que asumir el coste de los dispositivos, no le gusta. La dirección querrá comprar dispositivos tan baratos como sea posible y cuyo coste de mantenimiento sea también lo más bajo posible. Sin olvidar que los dispositivos deberían trabajar por lo menos tres años sin problemas para mantener el TCO.
- Por su parte, los administradores de sistemas preferirán dispositivos que sean fáciles de administrar, lo que significa tener la posibilidad de acceder a los dispositivos cuando sea necesario y que la gestión de los mismos no requiera demasiado esfuerzo.
Teniendo en cuenta todos estos intereses en conflicto, ¿cómo elegir el dispositivo correcto? Hay una serie de reglas que se deben seguir al seleccionar los dispositivos:
- Involucrar a todas las partes al principio del proyecto. Es especialmente importante que los usuarios finales se involucren, ya que son el factor decisivo para que un proyecto de movilidad sea un éxito. Si los usuarios finales no están contentos con los dispositivos seleccionados el proyecto no será un éxito.
- Probar varios dispositivos, incluyendo diferentes tipos de dispositivos como ordenadores portátiles, Tablet PCs y PDAs. Tener la mente abierta al hacer estas pruebas: es posible que ya se tenga una idea del tipo de dispositivo que se quiere, pero podría resultar que el dispositivo que se había pensado originalmente no sea el mejor dispositivo para su proyecto.
- Probar siempre los dispositivos más robustos, reforzados y resistentes a las malas condiciones ambientales (si estos dispositivos tienen sentido en su entorno). Es cierto que la inversión podría ser mayor al principio, pero el costo total de propiedad puede ser menor ya que estos dispositivos tendrán una vida útil superior que los no reforzados.
- Tomar la decisión sobre el dispositivo finalmente seleccionado junto con todas las partes involucradas.
Desde el punto de vista técnico, los aspectos a tener en cuenta en la selección del dispositivo, son los siguientes
- Duración de la batería: Demasiadas paradas para cambiar baterías afectará a la productividad de los usuarios finales.
- Rendimiento: los tiempos de espera deben reducirse al mínimo y el dispositivo debe poder trabajar bien con la aplicación.
- Memoria: debe ser suficiente para la aplicación que se va a ejecutar en el dispositivo.
- Robustez: Cuanto mas robusto, mayor será la vida útil del dispositivo.
- Facilidad de operación.
- Pantalla: lo fácil que es para los usuarios finales para leer los datos en la pantalla. La pregunta es ¿Es el tamaño de la pantalla suficiente para la aplicación?
- Almacenamiento de datos: ¿Qué opciones de almacenamiento de datos ofrece el dispositivo? ¿Son estas opciones suficientes para el funcionamiento de su aplicación?
- Accesibilidad: ¿Es fácil acceder a un dispositivo de forma remota en caso de problemas?
- Sistema Operativo: ¿Es un sistema operativo propio del dispositivo ó propio de la aplicación a ejecutar en el mismo?
- Estabilidad: El dispositivo tiene que ser lo más estable posible, ya que cada inestabilidad podría resultar en la pérdida de datos.
Como se puede ver, hay muchos factores a tener en cuenta al seleccionar un dispositivo móvil. Dedicar el suficiente tiempo a la selección de los dispositivos correctos supone en general dedicar menos tiempo después a la operación y el mantenimiento de los mismos.
