Desarrollo Forms,Java,C#,ExtJS,Customizaciones para EBS R12

Este blog esta dedicado a la publicación de artículos concernientes al desarrollo en diferentes lenguajes de programación, entre las tecnologías que publicaremos tenemos: - Programación en Oracle Forms y Reports, Java, C#, PHP, JavaScrip,Extjs - Diseño de reportes con JAsperReports así como algunas implementaciones de ERP's. Visita nuestro canal en youtube: https://www.youtube.com/channel/UC0NlrPdnL4x8Tb5BRzwKgUg suscribete y estaras al tanto de las novedades que publicaremos.

martes, 6 de enero de 2015

Creación de Objetos de Base de Datos en EBS

En esta ocasión hablaremos de cómo crear tablas y adicionar las columnas necesarias.

Uso del Optimizador Cost-Based de Oracle

Oracle E-Business Suite utiliza la Optimización Base-Costo (CBO) en lugar de la de optimización basada en reglas (RBO) utilizada en versiones anteriores. Todo nuevo código debe ser escrito para tomar ventaja de la optimización.

Seguimiento de los cambios con registros históricos (OMS)

La función Historial Record (OMS) reporta información sobre quién creó o actualizo filas en las tablas de Oracle E-Business Suite.
Si agrega columnas especiales de la OMS a las tablas y la lógica de la OMS a los formularios y procedimientos almacenados, los usuarios pueden realizar un seguimiento de los cambios realizados en sus datos. Al observar columnas de la OMS, los usuarios pueden diferenciar entre los cambios realizados por las formas y los cambios realizados por los programas concurrentes.
Usted puede representar cada una de las columnas de OMS como campos ocultos en cada bloque de sus formularios (que corresponden a las columnas de la OMS en cada tabla subyacente). Estos campos son llenados invocando a FND_STANDARD.SET_WHO en los eventos PRE-UPDATE y PRE-INSERT.

Cómo añadir columnas Histórico de Registro

La siguiente tabla muestra las columnas estándar utilizados para Historial (OMS), los atributos de la columna y descripciones, las fuentes de los valores de esas columnas. Establezca las columnas CREATED_BY y CREATION_DATE sólo cuando se inserta una fila (utilizando FND_STANDARD.SET_WHO de un formulario).

Nombre de Columna	Tipo	Null?	Foreign Key?	Descripcion	Valor
CREATED_BY	NUMBER(15)	NOT NULL	FND_ USER	Usuario que creo el registro	TO_NUMBER (FND_ PROFILE. VALUE ('USER_ID'))
CREATION_ DATE	DATE	NOT NULL		Fecha de creación de la fila	SYSDATE
LAST_ UPDATED_BY	NUMBER(15)	NOT NULL	FND_ USER	Usuario que actualizo el registro	TO_NUMBER (FND_ PROFILE. VALUE ('USER_ID'))
LAST_UPDATE_ DATE	DATE	NOT NULL		Fecha de la Ultima actualización	SYSDATE
LAST_UPDATE_ LOGIN	NUMBER(15)		FND_ LOGINS	Proporciona acceso a la información sobre el sistema operativo de inicio de sesión del usuario que la última actualización de cada fila	TO_NUMBER (FND_ PROFILE. VALUE ('LOGIN_ ID'))

Cualquier tabla que pueda ser actualizada por un programa concurrente también necesita columnas adicionales. La siguiente tabla muestra las columnas, los atributos de columna, descripciones, y las fuentes de los valores de esas columnas.

Nombre de Comuna	Tipo	Null?	Foreign Key to Table?	Descripción
REQUEST_ID	NUMBER(15)		FND_ CONCURRENT_ REQUESTS	ID del concurrente con el cual el registro fue credo o actualizado
PROGRAM_ APPLICATION_ ID	NUMBER(15)		FND_ CONCURRENT_ PROGRAMS	Id de programa con el cual el registro fue cread o actualizado
PROGRAM_ID	NUMBER(15)		FND_ CONCURRENT_ PROGRAMS	Id de programa con el cual el registro fue cread o actualizado
PROGRAM_ UPDATE_DATE	DATE		PROGRAM_ UPDATE_ DATE	Fecha de creación o actualización

Utilizar controladores de eventos con el Código de Registro de Historial en los formularios

Algunas operaciones que se deben realizar en el momento de realizar el commit no parecen estar diseñadas para un manejador de tabla. Por ejemplo, los controladores de eventos son preferibles a los manejadores de tablas para establecer información histórica de un registro, o la determinación de un número secuencial. La lógica de estas operaciones se puede almacenar en un PRE_INSERT y / o controlador de eventos PRE_UPDATE, PRE-INSERT y PRE_UPDATE son llamados a nivel de bloque cuando se disparan las inserciones o actualizaciones.

Clases de propiedad para los campos de la OMS

Aplicar la clase de propiedad CREATION_OR_LAST_UPDATE_DATE al campo CREATION_DATE en el formulario y LAST_UPDATE_DATE respectivamente. Estas clases de propiedad establecen los atributos correctos para estos campos, incluyendo el tipo de datos y el
ancho.

Tablas sin Información Histórica

Para los bloques que están basados en una tabla que no tienen columnas de información Historia, se debe deshabilitar el menú> ABOUT_THIS_RECORD (todos los demás casos se tratan mediante el control de menú por defecto), para ello se debe colcar en el evento WHEN-NEW-BLOQUE-INSTANCIA a nivel de bloque las siguientes líneas:

app_standard.event('WHEN-NEW-BLOCK-INSTANCE');

app_special.enable('ABOUT', PROPERTY_OFF);

Declaración de Restricciones en Oracle

En esta sección trataremos sobre las restricciones y permisos de base de datos y cuando utilizar cada función con las tablas personalizadas dentro de Oracle E-Business Suite.
Cualquier restricción que se asocia con una tabla debe ser duplicada en un formulario para que el usuario recibe retroalimentación inmediata si la restricción es viola.
Advertencia: No debe crear restricciones adicionales sobre las tablas de Oracle E-Business Suite, ya que puede afectar negativamente en las actualizaciones de Oracle E-Business Suite. Si crea limitaciones adicionales, es posible que necesite desactivarlas antes de actualizar Oracle E-Business Suite.

NOT NULL

Utilice siempre que sea apropiado. Declarar los campos correspondientes dentro de las formas de Oracle como "Requerido" = True.

DEFAULT

En general, no use esta función debido a problemas de bloqueo potenciales con Oracle Forms. Es posible que pueda utilizar esta función con las tablas que no son utilizados por las formas (por ejemplo, los utilizados por programas por lotes).

UNIQUE

La restricción "unique" impide la duplicación de claves alternas (no primarias), es decir, especifica que dos registros no puedan tener el mismo valor en un campo. Se permiten valores nulos.
Se pueden aplicar varias restricciones de este tipo a una misma tabla, y pueden aplicarse a uno o varios campos que no sean clave primaria.
Se emplea cuando ya se estableció una clave primaria (como un número de legajo) pero se necesita asegurar que otros datos también sean únicos y no se repitan (como número de documento).
La sintaxis general es la siguiente:

alter table NOMBRETABLA

add constraint NOMBRERESTRICCION

unique (CAMPO);

CHEQUE

La restricción "check" especifica los valores que acepta un campo, evitando que se ingresen valores inapropiados.
La sintaxis básica es la siguiente:

alter table NOMBRETABLA

add constraint NOMBRECONSTRAINT

check CONDICION;

Esto no suele ser un problema, ya que los factores desencadenantes de bases de datos Oracle E-Business Suite raramente deben ser desactivados. Algunos factores desencadenantes (como eventos de alerta) se desactivan antes de una actualización y re-activados al final de la actualización.
Se desaconseja el uso de triggers de base de datos.

PRIMARY KEY

Definir una clave principal para todas las tablas.

Cascade Delete and Foreign Key Constraint

No utilice el declarativa Cascade Delete or the Foreign Key Constraint en la definición de las tablas. Eliminar en cascada no funciona a través de bases de datos distribuidas, por lo que debe programar la lógica de eliminación en cascada.

Para llevar a cabo una verificación de la integridad referencial, cree un / SQL procedimiento almacenado PL que cuyo argumento sea la clave primaria y que lance una excepción si la supresión de la fila podría causar un error de integridad referencial.

LONG, LONG RAW y RAW Datatypes

No utilice estos tipos de datos en su lugar utilice : VARCHAR2(2000) en la declaración de las columnas

Uso de palabras Reservas en Columnas

Si una tabla contiene como nombre de columna una palabra reservada de PL/SQL o de Oracle Forms, se deberá crear una vista sobre esta tabla en la cual se pondrá un alias a estas columnas.

Views

En general, los bloques complejos se basan en las Vistas mientras que los bloques de configuración simples se basan en tablas. Las ventajas de utilizar vistas son:

El tráfico de red se reduce al mínimo, porque todas las claves externas se des normalizan en el servidor
No es necesario codificar ninguna lógica en POST-QUERY para rellenar los campos que no son de Base de datos
No es necesario codificar ninguna lógica en PRE-QUERY para implementar consulta por ejemplo para los campos que no son de base de datos

También debe basar sus listas de valores (LOV) en vistas. Esto le permite centralizar y compartir definiciones LOV. Una vista LOV suele ser más simple que una vista de bloque, ya que incluye menos columnas no normalizadas, y contiene sólo las filas válidas de datos.

Definir vistas para mejorar el rendimiento

Siempre que el rendimiento es un problema y su Tabla tiene las claves externas, debe definir una Vista con el objetivo de mejorar el rendimiento. Las vistas permiten una única sentencia SQL procesar las claves externas, reduciendo análisis sintácticos por el servidor, y reduciendo el tráfico de red.

Definir vistas para Impulsa la modularidad

Cualquier objeto disponible en la base de datos promueve la modularidad y reutilización, porque todo código del lado del cliente o del servidor puede acceder a él.
Las vistas son muy deseables porque:

Aceleran el desarrollo, ya que los desarrolladores pueden construir en ella lógica encapsulada
Ellas modula rizan código, a menudo lo que significa que una corrección o mejora pueden realizarse en una sola ubicación
Reducen el tráfico de red
A menudo son útiles para la presentación de informes u otras actividades
Pueden ser parcheado con facilidad y de forma centralizada en un sitio de cliente

Cuando no crear una Vista

Si la vista contiene una sola sentencia SQL NO se debería crear una vista.
Si la vista será utilizada por un solo procedimiento almacenado NO se debería crear, ya que esto aumenta la carga de mantenimiento debido a que tanto el código que contiene la sentencia de SQL y la vista debe ser mantenida.

ROW_ID primera columna

La primera columna de la vista debe ser la pseudo-columna ROWID de la tabla raíz, y la vista debe crear un alias a ROW_ID. Su vista, entonces debe incluir todas las columnas de la tabla raíz, incluyendo las columnas de la OMS, y debe des normalizar la información de las claves externas.
Consejo: Sólo tiene que incluir la columna ROWID si la vista es utilizada en un bloque de Oracle Forms. El campo de Oracle Forms correspondiente a la pseudo-columna ROW_ID debe utilizar la clase de propiedad ROW_ID.

Cambiar el Modo Clave (Block Key Mode)

En Oracle Forms, es necesario cambiar la propiedad Modo Clave (Block Key Mode) a "No Actualizable (Non-Updatable)" que no pueden actualizarse y asi de esta forma Fomrs no hara referencia por defecto a ROWID para bloques basados en vista. Especifique a nivel de ITEM la propiedad Clave Primaria (Primary Key) en True.
Por ejemplo, un punto de vista basado en la tabla EMP tiene las columnas row_id, EMPNO, Ename, deptno y DNAME. Establezca la propiedad Tecla de modo de bloque EMP_V a que no pueden actualizarse, y establezca la propiedad de clave principal de EMPNO en True.
Si el bloque se basa en una tabla, el Modo Clave (Block Key Mode) debe ser único.

Código desencadenantes de Inserción, Actualización, eliminación y bloqueo

Si el bloque se basa en una vista, se debe codificar los eventos ON-INSERT, ON-UPDATE ON-DELETE y ON-LOCK para insertar, actualizar, eliminar y bloquear la tabla raíz en lugar de la vista.

Vistas de una sola Tabla

Las Vistas individuales de una sola Tabla no necesitas los factores desencadenantes de inserción, actualización, supresión y bloqueo. El ajuste Modo Clave debe estar en "Unico". Las vistas de una sola tabla no requieren una columna ROW_ID.

Caracteres especiales

No utilice la función CHR () (se utiliza para definir un carácter por su número ASCII) en el lado del servidor. Esto causa problemas con las plataformas de servidor que utilizan EBCDIC, como MVS.

Secuencias

En esta sección trataremos sobre las normas para la creación y el uso de secuencias.

Crear Secuencias de Uso Individual

Use cada secuencia para suministrar valores de identificación únicos para una columna de una tabla.

No limite el alcance de su Secuencias

No debe crear secuencias que se envuelven con la opción CICLO o que tienen un MAXVALUE especificado. El rango total de la secuencia es tan grande que los límites superiores realista nunca se encuentran.

En general, no diseñar secuencias que se envuelven o tengan rangos limitados.

Tipo de Datos Para Almacenar Secuencias

Utilice un tipo de datos NUMBER para almacenar valores de secuencia dentro de PL / SQL.

No utilice la Tabla FND_UNIQUE_IDENTIFIER_CONTROL

No confíe en la tabla FND_UNIQUE_IDENTIFIER_CONTROL para suministrar valores secuenciales. Utilice una secuencia o en su lugar el paquete de numeración secuencial. La tabla FND_UNIQUE_IDENTIFIER_CONTROL es obsoleta y no debe tener ninguna fila para los objetos de su producto.

Además, no cree versiones específicas de la aplicación de la tabla FND para reemplazar la tabla FND_UNIQUE_IDENTIFIER_CONTROL.

API para el Registro de Tablas

Usted puede registrar sus tablas de aplicaciones personalizadas mediante una rutina de PL / SQL utilizando el paquete AD_DD.

Flexfields y Alerta Oracle son las únicas características o productos que dependen de esta información. Por lo tanto, sólo es necesario registrar esas tablas (y todas sus columnas) que se utilizarán con flexfields o Alerta Oracle.

También puede utilizar la API AD_DD para eliminar el registro de la tablas y columnas de Oracle Application Object Library , en caso de que más tarde tenga que modificar las tablas.

Si altera la tabla más adelante, entonces tiene que modificar el registro de la tabla dentro del EBS. Para modificar un registro primero debe eliminar el registro, a continuación volver a registrar la tabla o columna. Primero de debe eliminar el registro columna, luego el registro de la tabla.

Debe incluir las llamadas a las rutinas de registro de tabla en una secuencia de comandos PL / SQL. Aunque creamos nuestras tablas en nuestro propio esquema de aplicación, debemos ejecutar los procedimientos AD_DD contra el esquema APPS. Se debe confirmar los cambios para que tomen efecto.

El API AD_DD no comprueba la existencia de la tabla registrada o columna en el esquema de base de datos, pero sólo actualiza las tablas de AOL requeridos. Debe asegurarse de que existen las tablas y columnas registradas en realidad y tienen el mismo formato que el definido mediante la API AD_DD.

Procedimientos en el paquete AD_DD

procedure register_table (
p_appl_short_name in varchar2,
p_tab_name in varchar2,
p_tab_type in varchar2,
p_next_extent in number default 512,
p_pct_free in number default 10,
p_pct_used in number default 70);

procedure register_column(
p_appl_short_name in varchar2,
p_tab_name in varchar2,
p_col_name in varchar2,
p_col_seq in number,
p_col_type in varchar2,
p_col_width in number,
p_nullable in varchar2,
p_translate in varchar2,
p_precision in number default null,
p_scale in number default null);

procedure register_primary_key(
p_appl_short_name in varchar2,
p_key_name in varchar2,
p_tab_name in varchar2,
p_description in varchar2,
p_key_type in varchar2,
p_audit_flag in varchar2,
p_enabled_flag in varchar2);

procedure update_primary_key(
p_appl_short_name in varchar2,
p_key_name in varchar2,
p_tab_name in varchar2,
p_description in varchar2 default null,
p_key_type in varchar2 default null,
p_audit_flag in varchar2 default null,
p_enabled_flag in varchar2 default null);

procedure register_primary_key_column(
p_appl_short_name in varchar2,
  p_key_name in varchar2,
  p_tab_name in varchar2,
  p_col_name in varchar2,
  p_col_sequence in number);

procedure delete_primary_key_column(
p_appl_short_name in varchar2,
  p_key_name in varchar2,
  p_tab_name in varchar2,
  p_col_name in varchar2 default null);

procedure delete_table(
p_appl_short_name in varchar2,
p_tab_name in varchar2);

procedure delete_column(
p_appl_short_name in varchar2,
p_tab_name in varchar2,
p_col_name in varchar2);

Variable	Description
p_appl_short_ name	El nombre corto de la aplicación propietaria de la tabla(por lo general la aplicación personalizada).
p_tab_name	El nombre de la tabla (en letras mayúsculas).
p_tab_type	Use 'T' si es una tabla de transacciones (casi todas las tablas de aplicación), o 'S' para una tabla "datos semilla" (utilizado sólo por Oracle productos E-Business Suite).
p_pct_free	El porcentaje de espacio de cada uno de los elementos de la tabla, reservada para futuras actualizaciones de la tabla (1-99). La suma de p_pct_free y p_pct_used debe ser inferior a 100.
p_pct_used	Porcentaje mínimo de espacio utilizado en cada uno de los elementos de la tabla (1-99). La suma de p_pct_free y p_pct_used debe ser inferior a 100.
p_col_name	El nombre de la columna (en letras mayúsculas).
p_col_seq	El número de secuencia de la columna en la tabla (el orden en que la columna aparece en la definición de la tabla).
p_col_type	El tipo de columna ('NUMBER', 'VARCHAR2', 'DATE', etc.).
p_col_width	El tamaño de la columna (un número). Utilice 9 de columnas de tipo DATE, 38 para las columnas numéricas (a menos que tenga un ancho específico).
p_nullable	Utilice 'N' si la columna es obligatorio o 'Y' si la columna permite valores nulos.
p_translate	Use 'Y' si los valores de las columnas serán traducidos para un lanzamiento de productos de Oracle E-Business Suite (utilizado sólo por Oracle productos E-Business Suite) o 'N' si los valores no están traducidos (la mayoría de las columnas de la aplicación).
p_next_extent	El siguiente tamaño de extensión, en kilobytes. No incluya la 'K'.
p_precision	El número total de dígitos de un número.
p_scale	El número de dígitos a la derecha del punto decimal en un número.

Ejemplo del uso del paquete AD_DD
He aquí un ejemplo de cómo utilizar el paquete AD_DD para registrar una Tabla flexfield y sus columnas:

--REGISTRAMOS LA TABLA

execute ad_dd.register_table('FND','CUST_FLEX_TEST','T',8,10,90);

--REGISTRAMOS SUS COLUMNAS

execute ad_dd.register_column('FND','CUST_FLEX_TEST','APPLICATION_ID',1,'NUMBER',38,'N','N');

execute ad_dd.register_column('FND','CUST_FLEX_TEST','ID_FLEX_CODE',2,'VARCHAR2',30,'N','N');

execute ad_dd.register_column('FND','CUST_FLEX_TEST','LAST_UPDATE_DATE',3,'DATE',9,'N','N');

execute ad_dd.register_column('FND','CUST_FLEX_TEST','LAST_UPDATED_BY',4,'NUMBER',38,'N','N');

execute ad_dd.register_column('FND','CUST_FLEX_TEST','UNIQUE_ID_COLUMN',5,'NUMBER',38,'N','N');

execute ad_dd.register_column('FND','CUST_FLEX_TEST','UNIQUE_ID_COLUMN2',6,'NUMBER',38,'N','N');

execute ad_dd.register_column('FND','CUST_FLEX_TEST','SET_DEFINING_COLUMN',7,'NUMBER',38,'N','N');

execute ad_dd.register_column('FND','CUST_FLEX_TEST','SUMMARY_FLAG',8,'VARCHAR2',1,'N','N');

execute ad_dd.register_column('FND','CUST_FLEX_TEST','ENABLED_FLAG',9,'VARCHAR2',1,'N','N');

execute ad_dd.register_column('FND','CUST_FLEX_TEST','START_DATE_ACTIVE',10,'DATE',9,'N','N');

execute ad_dd.register_column('FND','CUST_FLEX_TEST','END_DATE_ACTIVE',11,'DATE',9,'N','N');

execute ad_dd.register_column('FND','CUST_FLEX_TEST','SEGMENT1',12,'VARCHAR2',60,'Y','N');

execute ad_dd.register_column('FND','CUST_FLEX_TEST','SEGMENT2',13,'VARCHAR2',60,'Y','N');

execute ad_dd.register_column('FND','CUST_FLEX_TEST','SEGMENT3',14,'VARCHAR2',60,'Y','N');

execute ad_dd.register_column('FND','CUST_FLEX_TEST','SEGMENT4',15,'VARCHAR2',60,'Y','N');

execute ad_dd.register_column('FND','CUST_FLEX_TEST','SEGMENT5',16,'VARCHAR2',60,'Y','N');

Bueno amigos eso es todo, gracias.

viernes, 28 de noviembre de 2014

Crear Procedimientos almacenados en Oracle con java para EBS R12

Java juega un papel importante en el espacio de desarrollo de aplicaciones de hoy en día.

Se ha vuelto cada vez más popular en los últimos años, debido a que es multiplataforma, potente y fácil de aprender. Aunque el desarrollo de Java no está directamente relacionada con PL / SQL, es importante para un desarrollador de PL / SQL aprender un poco acerca de Java, ya que hay algunos beneficios de usar java en las tareas de base de datos.

Oracle Database 11g contiene compatibilidad JVM con Java 1.5, que incluye cambios sustanciales en el lenguaje, por lo que es una plataforma aún más complementaria para el desarrollo. También a partir de Oracle 11g, la base de datos incluye un compilador Just-in-time, que compila el código de bytes de Java en instrucciones de lenguaje de máquina.

En este ocasión aprenderemos a combinar el poder de PL / SQL de con código Java que se almacena en la base de datos. Aprenderemos cómo crear procedimientos almacenados, funciones y disparadores utilizando el lenguaje Java, nos centraremos únicamente en el uso de los tipos de Java junto con las aplicaciones PL / SQL.

Para poder crear los programas java utilizaremos JDeveloper el cual viene incluido cuando instalamos oracle developer suite 10g (10 1 2 0 2), vamos a realizar una pequeña aplicación con la cual podamos consultar todos los pedidos de OM junto a sus documentos generados en AR y esta información la vamos a enviar a un correo determinado.

El formato del correo que enviaremos será HTML para es que vamos a desarrollar un programa que construya nuestro HTML.

Lo primero que haremos será obtener las tablas, vistas o Sinónimos que vamos a utilizar para armar el Query que utilizaremos.

Lo primero que haremos será iniciar sesión en el EBS y luego nos vamos a la responsabilidad “Order Management”, abrimos el formulario “Quick Sales Orders” buscamos un pedido ya tomado, colocamos el mouse donde dice “Customer”, luego nos vamos al menú “Help” y seleccionamos la opción “Record History”

Esto nos abrirá la siguiente ventana:

De esta pantalla lo que nos interesa es el dato resaltado con amarillo, podemos observar que se trata de una vista ya que en Oracle EBS R12 su standard de nombrado de objetos vistas dice que deben terminar el nombre con una V esto quiere decir <Modulo>_<Nombre Vista>_V, bueno con esta vista ya podemos obtener todos los pedidos pero necesitamos obtener los documentos aplicados a este pedido, para ello hacemos click derecho en cualquier campo de la cabecera del pedido y seleccionamos “Payment/View Invoices/Credits” tal como se muestra en al imagen:

Esto nos abrirá la siguiente pantalla:

En esta pantalla podemos observar los campos “Amount y Balance” los cuales representan el monto real del pedido y el saldo respectivamente, en este caso el saldo es “0” ya que el pedido fue cancelado en su totalidad.

Lamentablemente el truco que Aplicamos para ver la tabla o vista que es utilizada en esta pantalla lo único que nos queda es descargar el formulario e identificar la tabla mediante su definición de BLOCK, para ellos nos vamos a “Help/About Oracle Applications” tal y como se muestra en la siguiente imagen:

Esto nos abrirá la siguiente pantalla:

En esta pantalla podemos observar que el nombre del archivo que representa al formulario es “OEXOETEL” el cual esta resaltado con amarrillo, como dato adicional podemos observar la dirección en donde se encuentra el ejecutable de esta pantalla “/u01/oracle/<Instancia>/apps/apps_st/appl/ont/12.0.0/forms/US/OEXOETEL.fmx” en esta dirección es en donde se encuentra todos los archivos de los formularios compilados correspondientes a OM, este archivo no nos sirve necesitamos el archivo “FMB” para ello lo descargamos de la siguiente dirección tal y como se muestra en la imagen:

Todos los archivos FMB del EBS están en la dirección:

“/u01/oracle/<Instancia>/apps/apps_st/appl/au/12.0.0/forms/<Idioma>”

Una vez descargado el archivo procedemos abrirlo con form 10g

Necesitamos saber el nombre del bloque al cual queremos llegar para poder identificar la vista/Tabla que utiliza la pantalla, para ello volvemos al EBS y nos dirigimos “Help/Diagnostics/Examine” tal y como muestra la imagen

Esto nos abrirá la siguiente pantalla:

En esta pantalla podemos ver el nombre del block el cual es “VIEW_ORDER_INVOICE”, ubicamos este nombre en Oracle Developers forms:

Aquí podemos observar que el nombre de la vista es “oe_ra_cust_trx_hdr_perf_v”, la cual esta resaltado con rojo.

Si ejecutamos un select sobre esta vista en SQL Developer notaremos que no nos muestra ningún resultado:

Esto es debido a que la vista utiliza los métodos “OE_Invoice_PUB.get_order_number() y OE_Invoice_PUB.get_order_type()” los cuales obtienen el número de pedido y el tipo de pedido respectivamente, esta información la obtiene del formulario en el cual se encuentra actualmente, es por esta razón que cuando lo ejecutamos el select sobre la vista esta no nos devuelve nada ya que no nos encontramos en el formulario de toma de pedido.

Ya con toda esta información nuestro script quedaría de la siguiente forma:

Lo siguiente que vamos hacer es crear una vista con este query para después poderla utilizar

Presionamos aceptar y la vista será creada:

Ahora vamos a crear nuestras clases java las cuales vamos a subir luego al motor de Oracle, para ello abrimos JDeveloper:

Procedemos a crear una nueva Aplicación tal como se muestra en la imagen

Este proceso nos crea un proyecto vacío, lo eliminamos y creamos uno nuevo:

Nuestro proyecto tendrá la siguiente estructura:

Podemos observar algunos errores, esto es debido a que no hemos importado el driver de oracle.

Lo primero que vamos hacer es crear el “Deployment Profile” tal como se muestra en la imagen:

Seleccionamos el tipo “Loadjava and Stored Procedures” ya que este nos permite generar paquetes y procedimientos almacenados en Oracle, los cuales estarán directamente relacionados con nuestros métodos java, además también suben las clases java o Oracle al momento de generar el deploy.

Las propiedades de nuestro archivo deploy deberán quedar de la siguiente manera:

Con esto nos aseguramos que además de subir los archivos .class también suba los .java que son en los cuales está el código fuente.

Ahora procederemos a crear un paquete en nuestro deployment:

Una vez creado el paquete vamos a crear un procedimiento almacenado que apunte al método “Demo_Proc. getPedidoOmAr” el cual explicare más adelante :

Tal como se puede ver en la imagen el procedimiento recibe dos parámetros los cuales son vectores el uno es un vector de String y el otro es un vector de Objetos Double, ambos parámetros los hemos declarado en modo “OUT”, esto se lo realiza de esta forma ya que vamos a utilizar este procedimiento en un concurrente del EBS, para poder seleccionar el modo en las propiedades de un parámetro perteneciente a un método java estso deben declararse como arrays, si no se lo declarara así solo tendríamos un modo que sería el “IN”, nuestro deployment quedara así:

Hasta ahora solo hemos armado la estructura de nuestro proyecto, para poder publicar nuestro paquete en el motor debemos crear una conexión desde JDeveloper al motor el cual será utilizado para publicar nuestro código en Oracle.

Procedemos a crear nuestra conexión tal como se muestra en la imagen:

Ahora vamos a proceder a adicionar el driver de Oracle al proyecto y asi de esta forma no tengamos errores al probar nuestro código en JDeveloper, la imagen a continuación muestra los pasos a seguir para importar el archivo:

Ahora vamos a publicar nuestro código utilizando la conexión que creamos hace unos momentos, la imagen muestra lo que se debe hacer para publicar los archivos:

Este será nuestro resultado en JDeveloper:

Pues bien si nos dirigimos a la base de datos en el esquema APPS deberemos encontrar tanto el paquete como los objetos java creados, la imagen a continuación nos muestra los objetos en el motor:

Bueno vamos a explicar un poco las clases de nuestro proyecto:

Empecemos con la clase “Demo_Proc”:

Lo primero que debemos notar es que esta clase tiene un solo método el cual es para el que hemos creado un procedimiento almacenado en Oracle,tomar en cuenta que también todas las excepciones son capturadas y lanzadas asía arriba para que aquel que invoque este método las controle.

1.- El primer paso que realiza este meto es el de traer todo los pedidos con sus documento de OM, para utiliza una instancia de la clase “Datos”, posteriormente con los pedidos crea un a página HTML con ayuda de las clases “PageHTML y TablaHTML”.

2.- Una vez creada la página es enviada por correo con ayuda del método “EnviarMail” de la instancia datos.

Clase Datos:

De esta clase los utilizamos los métodos “getPedidoOmAr y EnviarMail”.

El método “getPedidoOmAr” es el que trae los pedidos de OM ejecutando el select contenido en la variable “SQL” y lo devuelve en un objeto ArrayList.

El método “EnviarMail” envía un correo al usuario especificado en la variable “Destinatario” invocando un procedimiento de la base de datos creado específicamente con este fin.

Podemos observar que en el método “EnviarMail” hay código comentado: