Ios

Angel F. Viartola

EnterpriseOne cuenta con unas cuantas herramientas y utilidades que son muy poco conocidas, y menos utilizadas, que facilitan muchas tareas de desarrollo y permiten simplificar procesos.

Por ejemplo, frente a la tradicional forma de gestionar ficheros de texto (abro fichero, leo líneas de una en una, cierro fichero) disponemos de la posibilidad de invocar a una función que se encarga de abrir el fichero, leerlo, subirlo a una tabla línea a línea, asignándole un número de lote, una descripción, incluso un código de informe y versión para que después pueda ser gestionado leyendo la tabla. Y todo esto únicamente invocando a una función de negocios. El leer un fichero de texto en una tabla permite utilizar cursores para leerlo en dos pasadas, o recorrerlo como queramos conveniente.

Disponemos de API’s que nos permiten leer las opciones de proceso de otras aplicaciones e informes, de manera que no necesitamos agregar opciones de proceso a una aplicación o hacer extrañas llamadas de unas a otras, podemos leer las que queramos desde donde queramos, añadir aplicaciones “dummy” que sólo se usen para asociarles más opciones de proceso, leer las de unas aplicaciones desde otras…

Tampoco solemos utilizar las directivas del preprocesador, opciones de compilación que nos permiten personalizar las funciones de negocio para que se compilen adecuadamente en cada una de las posibles máquinas, de forma que podamos tener código específico para Unix/Linux, Windows o AS/400 dentro de la misma función.

Uso de ftp para la gestión de objetos de medios, posibilidad de invocar directamente a los distintos “mafflets” pasándoles parámetros, inclusión de gráficos de barras o sectores en pantallas y otras muchas posibilidades a nuestra disposición para mejorar el rendimiento, la programación o la visualización de nuestras aplicaciones.

Os iremos contando más cosas.

Saludos.

Angel F. Viartola

En toda implantación de un sistema de gestión llega el momento de hablar de seguridad: copias de seguridad, qué usuarios pueden acceder a qué datos, o qué aplicaciones pueden ser usadas por distintos usuarios, quien puede generar determinados tipos de datos…

En mi experiencia como consultor de implantación de sistemas de gestión he encontrado que, normalmente, cuando se inicia un proyecto se comenta el tema, se explica al cliente las posibilidades de seguridad que tiene EnterpriseOne y a partir de ese momento se espera que sea la empresa quien decida qué tipos de empleado va a tener, qué va a poder hacer cada uno y todas las opciones de seguridad.

Las posibilidades de seguridad en EnterpriseOne son muy amplias: puedo limitar qué acciones puede efectuar un usuario en una pantalla, qué puntos de menú puede o no puede ver, qué filas o columnas de tablas puede visualizar, y opciones de seguridad más avanzadas, específicas algunas de EnterpriseOne, que además se pueden combinar con configuraciones de seguridad de la base de datos, puesto que el sistema permite que los usuarios de la aplicación utilicen distintos perfiles de usuario de base de datos, esto es, según a qué entornos de la aplicación entra su usuario de base de datos puede ser uno u otro, y siempre se respetará la configuración de seguridad de la base de datos añadida a la que se realice en EnterpriseOne.

Así pues, tenemos muchas posibilidades en cuestión de seguridad. Tenemos al usuario del sistema informado de estas posibilidades, tenemos un proyecto en marcha y, ¿qué suele ocurrir?

Normalmente el tema de seguridad se va retrasando, diluyendo en distintas áreas de responsabilidad y se termina por llegar a la fecha del arranque sin un modelo de seguridad adecuado, y es cuando deprisa y corriendo se pretende construir una estructura de la organización desde la que se deduzca la configuración de seguridad, lo que normalmente no funciona.

Y todo esto suele ocurrir porque al implementar la solución de gestión no se tiene en cuenta, desde el principio, que un cambio de herramienta puede conllevar cambios en la organización, así como cambios en la forma de trabajar (todos hemos oído la famosa frase “es que en mi sistema yo hago…”), y todos estos cambios deben intentar ser descubiertos y tenidos en cuenta durante la fase de implantación, así como la configuración de seguridad asociada a las nuevas metodologías de trabajo. Porque, si quieres que todo sea como antes, ¿por qué cambias el sistema?

Angel F. Viartola

En una implantación de EnterpriseOne llega el momento de hacer una personalización.  ¿Qué se hace? ¿Se copia el objeto estándar y se modifica o se trabaja directamente contra el estándar? Es un debate que frecuentemente se da en los foros de JD Edwards. Yo tengo mi opinión al respecto: modificar el estándar siguiendo las recomensaciones de Oracle, siempre y cuando sea posible.

¿Cuales son las razones que me hacen elegir esa opción?

Copiar los estándares modificados a objetos nuevos implica perder toda posibilidad de mantenimiento por parte de Oracle: los parches se aplican sobre programas del estándar JD Edwards, no sobre programas de usuario. Y además, bajo determinadas condiciones, la aplicación de un parche no va a suponer la pérdida de nuestras modificaciones, siempre y cuando se hayan hecho con la metodología adecuada. Oracle en su serie de documentos “EnterpriseOne Modifications General Recommendations and Guidelines” explica detalladamente cómo se debe modificar el estándar, qué cambios son fácilmente reaplicables, qué cambios se perderán en el caso de actualización

En uno de los documentos de esa serie (ott-03-0020) se señala lo siguiente:

“Should I make a copy or should I modify the standard object? This is a judgment call. If the application has a lot of ER, is heavily used, often requires ESU’s, and is a big part of the day’s daily process, then modifying the standard object may be the best option.

If you make a copy of an object, you are making a snapshot of that object at a point in time when the copy is performed. When an ESU becomes available for the standard PeopleSoft EntepriseOne application that fixes a bug or adds functionality to the object you copied, the change is not included for the copied custom object. You can not direct the changes in the ESU to any object you want, such as a copy of the same object the ESU is intended for. The changes in the ESU are only applied to the object they are intended for.  Therefore any changes would have to be manually retrofitted to the custom object when an ESU is applied.”

“¿Debo hacer una copia o debería modificar el objeto estándar? Este es un juicio personal. Si la aplicación tiene un montón de ER, es muy usada, a menudo requiere de ESU (parches de la aplicación), y es una gran parte del proceso diario, entonces modificar el objeto estándar puede ser la mejor opción.

Si usted hace una copia de un objeto, usted está haciendo la copia de objeto en un momento concreto. Cuando un ESU que se disponga para el estándar de EntepriseOne corrija un error o aumente la funcionalidad del objeto que se ha copiado, el cambio no se incluye en cada objeto personalizado copiado (únicamente en el objeto original). Usted no puede aplicar los cambios del ES  a cualquier objeto que desee, como por ejemplo una copia del objeto estándar. Los cambios en los ESU sólo se aplican al objeto que están destinados. Por lo tanto, cualquier modificación tendría que ser manualmente aplicada para el objeto personalizado cuando se aplique un ESU al objeto original.”

Esto es: trabajar con programas copiados implica perder el mantenimiento, perder las posibles ampliaciones de funcionalidad, perder todo soporte por parte de Oracle.

Utilizar el estándar siempre es la mejor opción, sólo hay que diseñar las personalizaciones bajo un prisma de conocimiento adecuado de la aplicación, saber qué se guarda y qué se pierde (”what preserves and what replaces”) cuando se hace una actualización y ser conscientes de lo que es el desarrollo en EnterpriseOne. Hay herramientas y técnicas más que suficientes tanto para personalizar como para reaplicar los cambios sin perder nada y con una inversión de tiempo mínima si se hacen las cosas correctamente.

Un saludo a todos.

Angel F. Viartola

Una de las afirmaciones sobre Oracle  JD Edwards EnterpriseOne es que es una aplicación independiente de la base de datos.

¿Qué significa “independiente de la base de datos”?

En muchas instalaciones de EnterpriseOne no se tiene en cuenta la posibilidad de que EnterpriseOne funcione de forma absolutamente independiente de la base de datos, siendo irrelevante que ésta sea Oracle, SQL Server o DB2. La aplicación es la misma en todos los casos, sólo variando en el proceso de instalación la forma de crear la base de datos o instalar el Enterprise Server, que lógicamente varía en función de la plataforma utilizada. Pero una vez realizada la instalación, desde el punto de vista de desarrollo y en el día a día, el hecho de que la base de datos o la plataforma sea una u otra es absolutamente irrelevante.

En muchas ocasiones encontramos que para realizar cargas de datos desde otros sistemas se exportan los datos a ficheros planos para después cargarlos de nuevo en JD Edwards, con lo que ello conlleva tanto a nivel de desarrollo como en posibilidades de error.

Pero si tenemos nuestro sistema corriendo en una BBDD Oracle y el control de almacén en SQL Server, ¿qué nos impide acceder directamente desde EnterpriseOne a una información almacenada en ese SQL Server? ¡¡Nada!!

Para tomar o dejar datos bastaría con crear un “Database Datasource” que apuntara al servidor al que queremos acceder, configurar el usuario de sistema adecuado, asociarlo al usuario que necesitar ese acceso y eso es todo: nos olvidamos de exportar, importar, carpetas de intercambio y demás complicaciones, simplificándolo y dejándolo en un acceso directo a la base de datos que necesitemos.

A partir de ahí la integración con otros sistemas, tanto a la hora de tomar como de dejar información se simplifica. Más aún cuando podemos jugar con toda la tecnología de JD Edwards a la hora de utilizar ese acceso: creación de pantallas, aplicaciones batch, uso del diccionario de datos, tablas, triggers de tabla, todo ello será perfectamente válido a la hora de acceder a esa nueva fuente de datos, sea o no una de las estándares de EnterpriseOne.

Probadlo… os sorprenderá.

Un saludo a todos.