Añadir a la recogida (s) Añadir a salvo
  1. Ninguna Categoria

Guía de desarrollo de software

Anuncio 
Región de Murcia
Consejería de Educación, Formación y Empleo
Avda. de La Fama, 15
Secretaría GeneralSecretaría General
Servicio de Gestión Informática
30006 MURCIA
www.carm.es/educacion
Guía de desarrollo de software
GUÍA DE DESARROLLO DE SOFTWARE _____________________________________________ 1
INTRODUCCIÓN ____________________________________________________________________ 2
ÁMBITO __________________________________________________________________________ 2
DESARROLLO EN ORACLE ____________________________________________________________ 2
Introducción ____________________________________________________________________ 2
Motivación _____________________________________________________________________ 2
Normas generales _______________________________________________________________ 3
Nomenclatura___________________________________________________________________ 3
Normas generales _____________________________________________________________________
Estilo del código ______________________________________________________________________
Tablas ______________________________________________________________________________
Identificadores _______________________________________________________________________
Funciones y procedimientos _____________________________________________________________
Otros objetos ________________________________________________________________________
Auditoria ___________________________________________________________________________
Diario ______________________________________________________________________________
3
3
3
4
4
5
5
7
Paquetes P _____________________________________________________________________ 8
Comentarios ____________________________________________________________________ 9
Generación automática de código __________________________________________________ 10
CONTROL DE ACCESO A USUARIO _____________________________________________________ 11
Motivación ____________________________________________________________________ 11
Identificación de usuarios ________________________________________________________ 11
Control de acceso a aplicación y procesos ___________________________________________ 11
Script de creación aplicación, procesos y grupos ______________________________________ 12
CONTROL DE VERSIONES ____________________________________________________________ 14
Introducción ___________________________________________________________________ 14
Metodología ___________________________________________________________________ 14
Clientes CVS __________________________________________________________________ 15
Repositorios ___________________________________________________________________ 16
Repositorio bd _________________________________________________________________ 16
Modificaciones ALTER (Carpeta Deltas) _______________________________________________ 17
Repositorio interno y externo ______________________________________________________ 17
Variables CVS _________________________________________________________________ 18
ENTORNOS_______________________________________________________________________ 19
Entorno de desarrollo ___________________________________________________________ 19
Entorno de preproducción o pruebas _______________________________________________ 20
Entorno de producción __________________________________________________________ 20
INSTALACIONES EN DESARROLLO _____________________________________________________ 21
INSTALACIÓN DE CÓDIGO EN PRUEBAS Y PRODUCCIÓN _____________________________________ 21
Motivación ____________________________________________________________________ 21
Aplicación de traspaso ___________________________________________________________ 21
Traspaso de código PL/SQL (DDL y DML) __________________________________________ 23
Traspaso de código aplicación (OAS, PHP,…) ________________________________________ 25
DESARROLLOS EN OAS _____________________________________________________________ 26
Plantillas y pantallas ____________________________________________________________ 27
Estructura en CVS ______________________________________________________________ 28
Normas _______________________________________________________________________ 28
DESARROLLOS EN JAVA ____________________________________________________________ 28
Estructura en CVS ______________________________________________________________ 28
VPN ___________________________________________________________________________ 28
Ubicación CVS: interno/recursos/documentacion/guia_desarrollo.doc
Pagina 1 de 29
Región de Murcia
Consejería de Educación, Formación y Empleo
Avda. de La Fama, 15
Secretaría GeneralSecretaría General
Servicio de Gestión Informática
30006 MURCIA
www.carm.es/educacion
Introducción
El Servicio de Gestión Informática de la Consejería de Educación,
Formación y Empleo de la Región de Murcia, en su compromiso de
mejora continua, ha creído conveniente mejorar sus procesos
relacionados con el desarrollo de aplicaciones.
El Servicio ha considerado que es necesario: estandarizar el
desarrollo de aplicaciones, automatizar tareas, identificar y
eliminar elementos de fallo, cumplir con la LOPD, …
Ámbito
Este documento surge como medio de comunicación con los
distintos participantes de un proyecto (jefes de proyecto, analistas y
programadores) ya sea interno o externo y siendo de obligada lectura
para participar en un proyecto de desarrollo de software para este
Servicio.
En el se explica la estandarización de código que usaremos, los
repositorios cvs, la instalación de código en producción, el control de
acceso … y otras muchas cosas que debemos saber para realizar un
proyecto para este Servicio.
Queda inicialmente fuera del ámbito de este documento la
descripción de las distintas fases empleadas en el desarrollo de software
(análisis, diseño, implementación, pruebas) así como la estandarización
de la documentación que se deba generar en cada una de estas fases.
Actualmente se esta trabajando para estandarizar esta documentación.
Desarrollo en Oracle
Introducción
La práctica totalidad de los proyectos de desarrollo del Servicio
usan Oracle como Sistema Gestor de Base de Datos.
La versión actual es Oracle 11g y concretamente es la 11.1.0.6 a 2
de Octubre del 2009.
Motivación
En esta sección se van a describir distintas normas a aplicar para
el diseño e implementación de los recursos de base de datos, con el fin
de conseguir que el código generado en los distintos proyectos tenga un
aspecto y estilo homogéneo.
Esta estandarización ofrece sus mayores ventajas en la fase de
mantenimiento, y más aún cuando muchas veces el personal de
mantenimiento es distinto del que participó en la creación del proyecto.
Ubicación CVS: interno/recursos/documentacion/guia_desarrollo.doc
Pagina 2 de 29
Región de Murcia
Consejería de Educación, Formación y Empleo
Avda. de La Fama, 15
Secretaría GeneralSecretaría General
Servicio de Gestión Informática
30006 MURCIA
www.carm.es/educacion
Normas generales




No están permitidos los sinónimos públicos
Antes de plantearse crear un dblink, debe solicitarse a los
responsables de los departamentos de sistemas y desarrollo
que estudiaran si es realmente necesario el dblink
Antes de plantearse crear un job, debe solicitarse a los
responsables de los departamentos de sistemas y desarrollo
que estudiaran si es realmente necesario el job
Siempre antepondremos el esquema para hacer referencia a
un objecto de bbdd ya sea una tabla, vista, procedimiento, ...
aunque sea es propietario del esquema es que usa el objecto.
Nomenclatura
La nomenclatura debe seguirse rigurosamente en los nuevos
proyectos.
Normas generales
Los identificadores estarán compuesto únicamente por los
siguientes caracteres: [A-Z] [a-z] [0-9] y [_].
Queda por tanto prohibido el uso de Ñ, ñ, acentos y demás
caracteres.
Estilo del código
Las palabras reservadas del lenguaje serán escritas en
mayúsculas: BEGIN, END, NUMBER, SUBSTR, REPLACE, ….
Tablas
Para nombrar las tablas:
 Emplearemos el plural.
o SOLICITUDES frente a SOLICITUD
o CUERPOS frente a CUERPO
 El nombre será auto-descriptivo aún siendo más largo
o SOLICITUDES frente a SOLI
 Tablas detalle
o Si tenemos la tabla SOLICITUDES, y necesitamos
una tabla detalle para los familiares la
nombraremos como SOLICITUDES_FAMILIARES
 Tablas detalle de tablas detalla
o Seguiremos el mismo criterio que para las tablas
detalle siempre que la longitud del nombre lo
permita
Ubicación CVS: interno/recursos/documentacion/guia_desarrollo.doc
Pagina 3 de 29
Región de Murcia
Consejería de Educación, Formación y Empleo
Avda. de La Fama, 15
Secretaría GeneralSecretaría General
Servicio de Gestión Informática
30006 MURCIA
www.carm.es/educacion
Es obligatorio crear comentarios tanto para la tabla como para
cada uno de sus campos. Será rechazado cualquier traspaso a
producción de tablas que no contenga comentarios.
El modelado de tablas debe ser aprobado por el encargado del
proyecto que será personal propio de la consejeria. Las empresas que
presenten un modelo deberán solicitar al encargado del proyecto que les
valide el modelo, haciendo este último hincapié en comprobar el
correcto uso de la nomenclatura y que NO se crear tablas que ya
existan en nuestra bbdd como tablas de centros, usuarios y demas.
Identificadores
Este apartado aplica tanto para los campos de las tablas como las
variables que empleemos en el PL/SQL.
Siempre que podamos intentaremos emplear la notación CAMEL
con los añadidos de la Notación Húngara, escribir los identificadores
con la primera letra de cada palabra en mayúsculas y el resto en
minúscula y emplear al principio un prefijo que indique alguna
característica del identificador, como su tipo en el caso de variables.
Ejemplo: nSalarioMinimo
Se puede optar por el empleo de prefijos para los identificadores
dependiendo del tipo:
 DATE  d
o Ejemplo: DINICIO
 VARCHAR2, CHAR, …  v
 NUMBER  n
 BOOLENA  b
 VARCHAR2(1) con valores S o N  b
o Cuando necesitamos un booleano en una tabla se
suele usar un varchar2(1) que solo admite S o N
debido a que Oracle no soporta BOOLEAN en SQL,
pero si en PL/SQL.
o En estos casos emplearemos también el prefijo b.
Funciones y procedimientos


NO se crearan procedimiento ni funciones como objetos
oracle independientes. En su lugar crearemos paquetes de
base de datos donde ubicaremos las funciones y
procedimientos.
Funciones de los paquetes
o Emplearemos como prefijo el correspondiente según el
tipo de dato que devuelve.
Ubicación CVS: interno/recursos/documentacion/guia_desarrollo.doc
Pagina 4 de 29
Región de Murcia
Consejería de Educación, Formación y Empleo
Avda. de La Fama, 15
Secretaría GeneralSecretaría General
Servicio de Gestión Informática


30006 MURCIA
www.carm.es/educacion
o Por ejemplo: FUNCTION nSalario RETURN NUMBER;
Procedimientos de los paquetes
o Intentaremos que tengan al comienzo el infinitivo de la
acción que realizar.
o Ejemplo: anularSolicitud, devolverRecibo
Parámetros de entrada
o Se les añadirá el carácter _ al final, con el fin de
distinguirlos de los propios campos las tablas y que
puedan dar lugar error de programación al usar
consultas.
Otros objetos







PRIMARY KEY  nombreTabla_PK
FOREIGN KEY  nombreTabla_tablaReferenciada_FK
CHECK  nombreTabla$nombreCampo_CK
UNIQUE INDEX  nombreTabla_U[1..n]
INDEX  nombreTabla_ I[1..n]
VISTAS  V_nombreVista
DISPARADOR  nombreTabla_descripcion_TR
Auditoria
Importante: El código necesario para cumplir con este apartado
será generado automáticamente según se explica en el apartado
“Generación automática de código”.
Definiremos auditoria como los campos adicionales a una tabla
que almacenan información sobre la operación de creación del registro
así como de la última operación que se realizó sobre el dicho registro.
Para cada tabla del modelo añadiremos una serie de campos de
auditoria. En sql sería algo así:
ALTER TABLE esquema.nombreTabla ADD
(
VAUDUSUAC
VARCHAR2(15 BYTE)
VAUDUSUA
VARCHAR2(15 BYTE)
VAUDOSUSUAC
VARCHAR2(15 BYTE)
VAUDOSUSUA
VARCHAR2(15 BYTE)
VAUDFUNCIONC VARCHAR2(80 BYTE)
VAUDFUNCION
VARCHAR2(80 BYTE)
DAUDFECHAC
DATE
DAUDFECHA
DATE
VAUDOPER
VARCHAR2(1 BYTE)
VAUDSETRAN
VARCHAR2(30 BYTE)
);
NOT
NOT
NOT
NOT
NOT
NOT
NOT
NOT
NOT
NOT
NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
NULL
COMMENT ON COLUMN esquema.nombreTabla.VAUDUSUAC IS 'Codigo del usuario que creo el
registro';
COMMENT ON COLUMN esquema.nombreTabla.VAUDUSUA IS 'Codigo del usuario que modifico el
registro';
Ubicación CVS: interno/recursos/documentacion/guia_desarrollo.doc
Pagina 5 de 29
Región de Murcia
Consejería de Educación, Formación y Empleo
Avda. de La Fama, 15
Secretaría GeneralSecretaría General
Servicio de Gestión Informática
30006 MURCIA
www.carm.es/educacion
COMMENT ON COLUMN esquema.nombreTabla.VAUDOSUSUAC IS 'Codigo del usuario de sistema que
creo el registro';
COMMENT ON COLUMN esquema.nombreTabla.VAUDOSUSUA IS 'Codigo del usuario de sistema que
modifico el registro';
COMMENT ON COLUMN esquema.nombreTabla.VAUDFUNCIONC IS 'Función que creo el registro';
COMMENT ON COLUMN esquema.nombreTabla.VAUDFUNCION IS 'Función que modifico el registro';
COMMENT ON COLUMN esquema.nombreTabla.DAUDFECHAC IS 'Fecha que se creó el registro';
COMMENT ON COLUMN esquema.nombreTabla.DAUDFECHA IS 'Fecha que se modificó el registro';
COMMENT ON COLUMN esquema.nombreTabla.VAUDOPER IS 'Operación';
COMMENT ON COLUMN esquema.nombreTabla.VAUDSETRAN IS 'Identificador único de la
transacción';
Si la tabla ya existia y tiene datos tendremos que hacerlo en dos
paso con un script como el siguiente:
ALTER TABLE esquema.nombreTabla ADD
(
VAUDUSUAC
VARCHAR2(15 BYTE),
VAUDUSUA
VARCHAR2(15 BYTE),
VAUDOSUSUAC
VARCHAR2(15 BYTE),
VAUDOSUSUA
VARCHAR2(15 BYTE),
VAUDFUNCIONC VARCHAR2(80 BYTE),
VAUDFUNCION
VARCHAR2(80 BYTE),
DAUDFECHAC
DATE
,
DAUDFECHA
DATE
,
VAUDOPER
VARCHAR2(1 BYTE) ,
VAUDSETRAN
VARCHAR2(30 BYTE)
);
COMMENT ON COLUMN esquema.nombreTabla.VAUDUSUAC IS 'Codigo del usuario que creo el
registro';
COMMENT ON COLUMN esquema.nombreTabla.VAUDUSUA IS 'Codigo del usuario que modifico el
registro';
COMMENT ON COLUMN esquema.nombreTabla.VAUDOSUSUAC IS 'Codigo del usuario de sistema que
creo el registro';
COMMENT ON COLUMN esquema.nombreTabla.VAUDOSUSUA IS 'Codigo del usuario de sistema que
modifico el registro';
COMMENT ON COLUMN esquema.nombreTabla.VAUDFUNCIONC IS 'Función que creo el registro';
COMMENT ON COLUMN esquema.nombreTabla.VAUDFUNCION IS 'Función que modifico el registro';
COMMENT ON COLUMN esquema.nombreTabla.DAUDFECHAC IS 'Fecha que se creó el registro';
COMMENT ON COLUMN esquema.nombreTabla.DAUDFECHA IS 'Fecha que se modificó el registro';
COMMENT ON COLUMN esquema.nombreTabla.VAUDOPER IS 'Operación';
COMMENT ON COLUMN esquema.nombreTabla.VAUDSETRAN IS 'Identificador único de la
transacción';
UPDATE esquema.nombreTabla
SET VAUDUSUAC = 'Desconocido',
VAUDUSUA = 'Desconocido',
VAUDOSUSUAC = 'Desconocido',
VAUDOSUSUA = 'Desconocido',
VAUDFUNCIONC = 'Se crea la auditoria',
VAUDFUNCION = 'Se crea la auditoria',
Ubicación CVS: interno/recursos/documentacion/guia_desarrollo.doc
Pagina 6 de 29
Región de Murcia
Consejería de Educación, Formación y Empleo
Avda. de La Fama, 15
Secretaría GeneralSecretaría General
Servicio de Gestión Informática
DAUDFECHAC
DAUDFECHA
VAUDOPER
VAUDSETRAN
30006 MURCIA
www.carm.es/educacion
= sysdate,
= sysdate,
= 'I',
= 'Desconocido';
ALTER TABLE esquema.nombreTabla MODIFY (
VAUDUSUAC
VARCHAR2(15 BYTE) NOT NULL,
VAUDUSUA
VARCHAR2(15 BYTE) NOT NULL,
VAUDOSUSUAC
VARCHAR2(15 BYTE) NOT NULL,
VAUDOSUSUA
VARCHAR2(15 BYTE) NOT NULL,
VAUDFUNCIONC VARCHAR2(80 BYTE) NOT NULL,
VAUDFUNCION
VARCHAR2(80 BYTE) NOT NULL,
DAUDFECHAC
DATE
NOT NULL,
DAUDFECHA
DATE
NOT NULL,
VAUDOPER
VARCHAR2(1 BYTE) NOT NULL,
VAUDSETRAN
VARCHAR2(30 BYTE) NOT NULL
);
Estos campos no será necesario rellenarlos en una operación de
INSERT ya que será un Trigger el encargado de rellenar estos campos.
Antes de hacer una modificación en los datos de la tabla será
necesario iniciar la auditoria. Para ello ejecutaremos lo siguiente:
CONTROLAPLIC.SESION.NOMBREPROGRAMA (vFormulario);
CONTROLAPLIC.SESION.NOMBREAPLICACION (vAplicacion);
Si no ejecutamos lo anterior no se podrán hacer modificaciones
en la tabla.
Diario
Importante: El código necesario para cumplir con este apartado
será generado automáticamente según se explica en el apartado
“Generación automática de código”.
Definiremos diario como una tabla de historio de todas las
operaciones realizadas sobre los registros de una tabla en la que
almacenamos los propios valores de los registros más una información
de auditoria.
Como regla general para cada tabla se creará otra de diario donde
quedarán reflejadas todas las operaciones que se realicen sobre los
registros de la tabla.
La tabla se nombrará anteponiendo el prefijo D al nombre de la
tabla original. Por ejemplo DCUERPOS será el diario de la tabla
CUERPOS.
Esta tabla será alimentada por un trigger que existirá en la tabla
del modelo. A su vez esta tabla tendrá una auditoria y por tanto un
trigger de auditoria.
Ubicación CVS: interno/recursos/documentacion/guia_desarrollo.doc
Pagina 7 de 29
Región de Murcia
Consejería de Educación, Formación y Empleo
Avda. de La Fama, 15
Secretaría GeneralSecretaría General
Servicio de Gestión Informática
30006 MURCIA
www.carm.es/educacion
Paquetes P
Importante: El código necesario para cumplir con este apartado
será generado automáticamente según se explica en el apartado
“Generación automática de código”.
Se creará un paquete P por cada tabla del modelo.
A continuación pongo un ejemplo reducido de cómo sería el
paquete p generado para la tabla XX.SOLICITUDES, cuya clave es
vSolicitud. En importante que leáis el código por que en los comentarios
encontrareis la explicación de las funciones típicas que debemos usar,
CREATE OR REPLACE PACKAGE XX.SOLICITUDES IS
/*
*
*
*
*
*
*
*
*
*/
Funcion existe --------------------------------------Comprueba la existencia de un registro. Identificado de
forma única con los parámetros de la funcion. Actualiza
el estado interno del Package para que los campos de
de la misma puedan ser recuperado por medio de una llamada
a las funciones de campo.
Entrada: Clave primaria de la tabla PUESTOS
Salida: TRUE si existe el registro, FALSE en caso contrario.
FUNCTION existe(vSolicitudes_ SOLICITUDES.VSOLICITUD%TYPE)
RETURN BOOLEAN;
PRAGMA RESTRICT_REFERENCES (existe, WNDS,RNPS);
FUNCTION vExiste(vpuesto_ PUESTOS.VPUESTO%TYPE)
RETURN VARCHAR2;
PRAGMA RESTRICT_REFERENCES (vExiste, WNDS);
/*
* Procedimiento borrar --------------------------------------* Procedimiento encargado de borrar un registro de la tabla
* Entrada: Clave primaria de la tabla
*/
PROCEDURE borrar(vpuesto_ PUESTOS.VPUESTO%TYPE);
PRAGMA RESTRICT_REFERENCES (borrar, WNPS, RNPS);
/*
* Procedimiento insertar --------------------------------------* Procedimiento encargado de insertar en la tabla PUESTOS
* el registro que se le pasa como parámetro
*
Entrada: Registro de tipo PUESTOS%ROWTYPE
*/
PROCEDURE insertar(rPuestos_ LINODO.PUESTOS%ROWTYPE);
PRAGMA RESTRICT_REFERENCES (insertar, WNPS, RNPS);
/*
*
*
*
*
*
*
*
Funcion tieneHijos ------------------------------------------Comprueba si tiene registros hijos asociados, para ello realizamos la
llamada a cada una de las funciones tiene<tablaHija>. Cada vez que
se cree una nueva tabla hija será necesario modificar el cuerpo de la
funcion y añadir la nueva sentencia ELSIF con dicha llamada.
Entrada: Clave primaria de la tabla MODALIDADES
Salida: TRUE si existen registros en las tablas hijas
Ubicación CVS: interno/recursos/documentacion/guia_desarrollo.doc
Pagina 8 de 29
Región de Murcia
Consejería de Educación, Formación y Empleo
Avda. de La Fama, 15
Secretaría GeneralSecretaría General
Servicio de Gestión Informática
*
*/
30006 MURCIA
www.carm.es/educacion
FALSE en caso contrario
FUNCTION tieneHijos(vmodalidad_ MODALIDADES.VMODALIDAD%TYPE,
vtipo_ MODALIDADES.VTIPO%TYPE,
vTexto OUT VARCHAR2)
RETURN BOOLEAN;
PRAGMA RESTRICT_REFERENCES (tieneHijos, WNDS);
-- Funciones de control de claves unicas ----------------$ Fin de funciones a documentar
-- Funciones de recuperacion de campos -------------/*
*
*
*
*
*/
Funcion de campo que recupera el valor del campo VCENTRO.
Entrada:
Salida: Valor del campo Registro.
Pre: Anteriormente se debe llamar a la función existe
FUNCTION vcentro
RETURN VARCHAR2;
PRAGMA RESTRICT_REFERENCES (vcentro,RNDS,WNDS,WNPS);
END;
/
Como regla general la lógica cuando debamos programar un
proceso los colocaremos en el paquete P de la tabla que almacena
la entidad principal con la que opera el proceso.
Por ejemplo si tenemos que crear el procedimiento
“anularSolicitud” el sitio donde colocar este procedimiento será en el
paquete P de la tabla SOLICITUDES.
Comentarios
Como no puede ser de otro modo el código debe comentarse lo
máximo posible hasta el punto que deberíamos ser capaces de entender
un algoritmo solo con las tabulaciones y los comentarios.
Una buena costumbre es poner los comentarios de lo que vamos a
hacer antes de programarlo.
Muestro a continuación un ejemplo de un código que esta bien
comentado:
--- Eliminar centros antiguos
--- Recorro todos los centros
<<recorrerCentros>>
FOR r IN cCentros LOOP
Ubicación CVS: interno/recursos/documentacion/guia_desarrollo.doc
Pagina 9 de 29
Región de Murcia
Consejería de Educación, Formación y Empleo
Avda. de La Fama, 15
Secretaría GeneralSecretaría General
Servicio de Gestión Informática
30006 MURCIA
www.carm.es/educacion
-- Si el centro es antiguo lo elimino
IF antiguo(r.vCodCentro) THEN
-- Elimino el centro
CENTROS.pCentros.eliminar(r.vCodCentro);
END IF;
END LOOP <<recorrerCentros>>;
Generación automática de código
Existe una aplicación que nos permite generar los paquetes P, la
tabla de diario, y los triggers de diario y auditoria.
Se puede acceder a esta aplicación a través de la url: http://vmoas-des1.edu.carm.es:7777/forms/frmservlet?config=segi , si tiene
problemas con el DNS actualmente la IP es la 147.84.65.171.
Si no podemos entrar a la aplicación pediremos el acceso al
personal del departamento de desarrollo.
Una vez dentro de la aplicación, buscaremos en el menú la opción
“Generación de código”  “Generar código”, la cual al entrar nos pedirá
el usuario y clave del esquema del que queremos generar código.
La pantalla tiene el siguiente aspecto:
Ubicación CVS: interno/recursos/documentacion/guia_desarrollo.doc
Pagina 10 de 29
Región de Murcia
Consejería de Educación, Formación y Empleo
Avda. de La Fama, 15
Secretaría GeneralSecretaría General
Servicio de Gestión Informática
30006 MURCIA
www.carm.es/educacion
Control de acceso a usuario
Motivación
Para un usuario es más sencillo tener un “login” y un “password”
global a todas las aplicaciones que uno por cada aplicación. También
resulta más sencillo para el Servicio gestionar un solo “logín” por
usuario que uno por usuario y aplicación.
La identificación, la autorización a las distintas funciones, las
pantallas de identificación, el menú de aplicación y demás elementos
relacionados son tareas que una vez hechas no se deberían volver a
implementar para cada aplicación.
Por todo esto se han creado una serie de herramientas
horizontales que ofrece la plataforma de desarrollo.
Entre estas existen la aplicación ControlAplic, que permite crear
aplicaciones, proceso, grupos de usuarios, usuarios, dar de alta
usuarios en grupos, grupos en aplicaciones etc …
Identificación de usuarios
Para identificar un usuario usaremos el siguiente código:
IF CONTROLAPLIC.VALIDA_PAS(:DATOS.USUARIO, :DATOS.CONTRA) = 1 THEN
-- Clave válida
ELSE
-- Clave INválida
END IF;
Para desarrollos OAS no será necesario programar esto. Ver
sección “Desarrollos en OAS”. Pantalla ENTRADA.fmb
Control de acceso a aplicación y procesos
Para controlar el acceso de un usuario a una aplicación usaremos
el siguiente código, el cual además nos ofrece la clave con la que
ejecutar la aplicación:
-- Me conecto con la cadena de la aplicación
vConexionAplicacion_ := CONTROLAPLIC.APLICACION_STATUS(vAplicacion);
-- Conectar LOGON
-- Establezco el login de usuario.
CATALOGO.USERUTIL.establecer_user(UPPER(:DATOS.USUARIO));
Para el acceso a un proceso, pantalla o informe usaremos un
código equivalente a:
-- Compruebo el acceso
IF NOT SUBSTR(CONTROLAPLIC.AUTORIZA(UPPER(CATALOGO.USERUTIL.OSUSER),
Ubicación CVS: interno/recursos/documentacion/guia_desarrollo.doc
Pagina 11 de 29
Región de Murcia
Consejería de Educación, Formación y Empleo
Avda. de La Fama, 15
Secretaría GeneralSecretaría General
Servicio de Gestión Informática
30006 MURCIA
www.carm.es/educacion
vAplicacion,
vFormulario), 1, 1) = 'S' THEN
-- Si no tiene acceso muestro el error y salgo de la pantalla
Mensaje  'No tiene permisos suficientes para ejecutar la pantalla'
RAISE EXCEPTION;
END IF;
Para desarrollos OAS no será necesario programar esto. Ver
sección “Desarrollos en OAS”. Pantallas con herencia a PLANTILLA.fmb,
trigger PRE-FORM.
Script de creación aplicación, procesos y grupos
Podemos usar la aplicación ControlAplic para crear una
aplicación, sus procesos, grupos y usuarios.
En todo caso y hasta que no dispongamos de una utilidad para
traspasar la información existente sobre una aplicación en ControlAplic
desde desarrollo a producción tendremos que generar los SQL
necesarios para dar de alta la aplicación en la base de datos de
producción.
Por este motivo voy a poner a continuación un ejemplo,
concretamente el usado en la aplicación SEGI.
--- Damos de alta la aplicación. Tabla CONTROLAPLIC.APLICACIONES
--- Damos de alta la aplicación SEGI
INSERT INTO CONTROLAPLIC.APLICACIONES
(APLICACION, DESCRIPCION, ACTIVA, USUARIO_ORACLE, PASSWORD_ORACLE,
CONTROL_ACCESOS, BASE_DATOS, TIPO, AMBITO, vrepositorio, bAutoInstala)
VALUES
('SEGI', 'Aplicación del Servicio de Gestión Informática', 'S',
'SEGI', 'catalogo', NULL, 'DESA', NULL, 'F', 'interno', 'S');
--- Creamos los grupos. Tabla CONTROLAPLIC.USUARIOS, GRUPO = 'S'
-- Los nombraremos como NOMBREAPLICACION_NOMBREGRUPO
-- Creamos el grupo SEGI_ADMIN
INSERT INTO CONTROLAPLIC.USUARIOS(
LOGIN, APN, GRUPO, DESCRIPCION,
F_ALTA, ACTIVO, USUARIO_ALTA, USUARIO_BAJA, F_BAJA )
VALUES ('SEGI_ADMIN', NULL, 'S', 'Administadores de SEGI',
-SYSDATE, 'S', 'VIS07W', NULL, NULL);
-- Creamos el grupo SEGI_USUARIOS
INSERT INTO CONTROLAPLIC.USUARIOS(
LOGIN, APN, GRUPO, DESCRIPCION,
F_ALTA, ACTIVO, USUARIO_ALTA, USUARIO_BAJA, F_BAJA )
VALUES ('SEGI_USU', NULL, 'S', 'Usuarios de SEGI',
-SYSDATE, 'S', 'VIS07W', NULL, NULL);
--- Damos de alta los procesos. Tabla CONTROLAPLIC.PROCESOS_APLICACIONES
Ubicación CVS: interno/recursos/documentacion/guia_desarrollo.doc
Pagina 12 de 29
Región de Murcia
Consejería de Educación, Formación y Empleo
Avda. de La Fama, 15
Secretaría GeneralSecretaría General
Servicio de Gestión Informática
30006 MURCIA
www.carm.es/educacion
--- Damos de alta los procesos: traspaso, ModuloGeneracionCodigo
INSERT INTO CONTROLAPLIC.PROCESOS_APLICACIONES(APLICACION, PROCESO, DESCRIPCION, ACTIVO)
VALUES('SEGI', 'MENU', 'Menú de la aplicación', 'S');
INSERT INTO CONTROLAPLIC.PROCESOS_APLICACIONES(APLICACION, PROCESO, DESCRIPCION, ACTIVO)
VALUES('SEGI', 'SOLICITARTRASPASOS', 'Solicitar traspasos', 'S');
INSERT INTO CONTROLAPLIC.PROCESOS_APLICACIONES(APLICACION, PROCESO, DESCRIPCION, ACTIVO)
VALUES('SEGI', 'REALIZARTRASPASOS', 'Realizar traspasos', 'S');
INSERT INTO CONTROLAPLIC.PROCESOS_APLICACIONES(APLICACION, PROCESO, DESCRIPCION, ACTIVO)
VALUES('SEGI', 'CONSULTARTRASPASOS', 'Consultar traspasos', 'S');
INSERT INTO CONTROLAPLIC.PROCESOS_APLICACIONES(APLICACION, PROCESO, DESCRIPCION, ACTIVO)
VALUES('SEGI', 'GENERARCODIGO', 'Generar código ', 'S');
--- Doy de alta los permisos sobre los procesos
-INSERT INTO USUARIOS_PROCESOS(
USUARIO, APLICACION, PROCESO, INSERTAR, EDITAR, BORRAR, ACTIVO )
VALUES('SEGI_ADMIN', 'SEGI', 'SOLICITARTRASPASOS', 'S', 'S', 'S', 'S');
INSERT INTO USUARIOS_PROCESOS(
USUARIO, APLICACION, PROCESO, INSERTAR, EDITAR, BORRAR, ACTIVO )
VALUES('SEGI_ADMIN', 'SEGI', 'REALIZARTRASPASOS', 'S', 'S', 'S', 'S');
INSERT INTO USUARIOS_PROCESOS(
USUARIO, APLICACION, PROCESO, INSERTAR, EDITAR, BORRAR, ACTIVO )
VALUES('SEGI_ADMIN', 'SEGI', 'CONSULTARTRASPASOS', 'N', 'N', 'N', 'S');
INSERT INTO USUARIOS_PROCESOS(
USUARIO, APLICACION, PROCESO, INSERTAR, EDITAR, BORRAR, ACTIVO )
VALUES('SEGI_ADMIN', 'SEGI', 'GENERARCODIGO', 'S', 'S', 'S', 'S');
INSERT INTO USUARIOS_PROCESOS(
USUARIO, APLICACION, PROCESO, INSERTAR, EDITAR, BORRAR, ACTIVO )
VALUES('SEGI_USU', 'SEGI', 'SOLICITARTRASPASOS', 'S', 'S', 'S', 'S');
INSERT INTO USUARIOS_PROCESOS(
USUARIO, APLICACION, PROCESO, INSERTAR, EDITAR, BORRAR, ACTIVO )
VALUES('SEGI_USU', 'SEGI', 'CONSULTARTRASPASOS', 'N', 'N', 'N', 'S');
INSERT INTO USUARIOS_PROCESOS(
USUARIO, APLICACION, PROCESO, INSERTAR, EDITAR, BORRAR, ACTIVO )
VALUES('SEGI_USU', 'SEGI', 'GENERARCODIGO', 'S', 'S', 'S', 'S');
INSERT INTO USUARIOS_PROCESOS(
USUARIO, APLICACION, PROCESO, INSERTAR, EDITAR, BORRAR, ACTIVO )
VALUES('SEGI_ADMIN', 'SEGI', 'MENU', 'S', 'S', 'S', 'S');
INSERT INTO USUARIOS_PROCESOS(
USUARIO, APLICACION, PROCESO, INSERTAR, EDITAR, BORRAR, ACTIVO )
VALUES('SEGI_USU', 'SEGI', 'MENU', 'S', 'S', 'S', 'S');
--- Doy de alta algunos usuario en los grupos: SEGI_ADMIN y SEGI_USU
--- Doy de alta el usuario vis07w
INSERT INTO CONTROLAPLIC.USUARIOS(
LOGIN, APN, GRUPO, DESCRIPCION, OU, NDS_CONTEXT,
F_ALTA, ACTIVO, USUARIO_ALTA, USUARIO_BAJA, F_BAJA )
VALUES ('VIS07W', 'Víctor Illán Sánchez', 'N', '',
-- Solo es necesario para las aplicaciones ditribuieda por novellNo es necesario
'SERVICIO DE GESTION INFORMATICA',
Ubicación CVS: interno/recursos/documentacion/guia_desarrollo.doc
Pagina 13 de 29
Región de Murcia
Consejería de Educación, Formación y Empleo
Avda. de La Fama, 15
Secretaría GeneralSecretaría General
Servicio de Gestión Informática
30006 MURCIA
www.carm.es/educacion
'INFORMATICA.LA_FAMA',
-SYSDATE, 'S', 'VIS07W', NULL, NULL);
-- Le doy a vis07w el grupo SEGI_USU y SEGI_ADMIN. Tambien se lo doy al grupo admin
INSERT INTO USUARIOS_GRUPOS(USUARIO, GRUPO )
VALUES ('ADMIN', 'SEGI_ADMIN');
INSERT INTO USUARIOS_GRUPOS(USUARIO, GRUPO )
VALUES ('ADMIN', 'SEGI_USU');
INSERT INTO USUARIOS_GRUPOS(USUARIO, GRUPO )
VALUES ('VIS07W', 'SEGI_ADMIN');
INSERT INTO USUARIOS_GRUPOS(USUARIO, GRUPO )
VALUES ('VIS07W', 'SEGI_USU');
--- Creo las estructura de menu
-INSERT INTO MENU_APLICACIONES (MENU, APLICACION, PROCESO, ACTIVA, PADRE, TEXTO)
VALUES (1, 'SEGI', NULL, 'S', NULL, 'Traspaso de código');
INSERT INTO MENU_APLICACIONES (MENU, APLICACION, PROCESO, ACTIVA, PADRE, TEXTO)
VALUES (2, 'SEGI', 'SOLICITARTRASPASOS', 'S', 1, NULL);
INSERT INTO MENU_APLICACIONES (MENU, APLICACION, PROCESO, ACTIVA, PADRE, TEXTO)
VALUES (3, 'SEGI', 'REALIZARTRASPASOS', 'S', 1, NULL);
INSERT INTO MENU_APLICACIONES (MENU, APLICACION, PROCESO, ACTIVA, PADRE, TEXTO)
VALUES (4, 'SEGI', 'CONSULTARTRASPASOS', 'S', 1, NULL);
INSERT INTO MENU_APLICACIONES (MENU, APLICACION, PROCESO, ACTIVA, PADRE, TEXTO)
VALUES (5, 'SEGI', NULL, 'S', NULL, 'Generación de código');
INSERT INTO MENU_APLICACIONES (MENU, APLICACION, PROCESO, ACTIVA, PADRE, TEXTO)
VALUES (6, 'SEGI', 'GENERARCODIGO', 'S', 5, NULL);
Control de versiones
Introducción
Usaremos un repositorio CVS para almacenar el código de
nuestras aplicaciones. No será posible subir, instalar o ejecutar un
fichero a producción mientras este no se suba a CVS.
Metodología
Siempre que se desee modificar un fichero del CVS, por ejemplo el
correspondiente a un paquete de base de datos, nos aseguraremos que
nadie esta editando el fichero.
Existen varias vertientes en el uso en grupo de CVS, nosotros nos
vamos a quedar con una intermedia. El proceso para modificar el
fichero será el siguiente
 Actualizar el fichero  cvs update nombreFichero
 Miraremos lo editores que hay actualmente en el fichero  cvs
editors nombreFichero
Ubicación CVS: interno/recursos/documentacion/guia_desarrollo.doc
Pagina 14 de 29
Región de Murcia
Consejería de Educación, Formación y Empleo
Avda. de La Fama, 15
Secretaría GeneralSecretaría General
Servicio de Gestión Informática



30006 MURCIA
www.carm.es/educacion
Si no hay, marcaremos la edición reservada  cvs edit –c
nombreFichero
Terminado el trabajo entregaremos  cvs commit
nombreFichero
Si queremos abortar la edición  cvs unedit nombreFichero
Otra vertiente de trabajo que puede adoptar un grupo de trabajo,
queda a criterio del grupo, es la de usar bloqueo de fichero en lugar del
concepto de editor. Si un fichero esta bloqueado no se podrá bloquear ni
subir por otra persona distinta de la que impuso el bloqueo, Los
comandos son:
 Bloquear: cvs admin –l nombreFichero
 Desbloquear: cvs admin –u nombreFichero
Clientes CVS
Existen muchos clientes CVS. Pongo aquí una lista de clientes:
 WinCVS
o WinCVS
 Es el mejor para trabajar en grupo puesto que integra
las funciones de edición en el menú
 http://www.wincvs.org/download.html
o TortoiseCVS
 Es el más sencillo, se integra en el menú contextual
de Windows
 Se puede usar sobre el mismo checkout que el
WinCVS
 No lleva todas las opciones necesarias. Por ejemplo
no permite hacer una edición reservada pero tiene la
opción “orden” en el que podemos poner por ejemplo
“cvs edit –c”. El programa guardan esta orden y la
próxima vez no será necesario teclear el comando

Si es checkout se almacena en una unidad de red
debemos activar la opción: Menú Contextual  CVS
Ubicación CVS: interno/recursos/documentacion/guia_desarrollo.doc
Pagina 15 de 29
Región de Murcia
Consejería de Educación, Formación y Empleo
Avda. de La Fama, 15
Secretaría GeneralSecretaría General
Servicio de Gestión Informática
30006 MURCIA
www.carm.es/educacion
 Preferencias  Directivas  Permitir unidades de
red
 http://www.tortoisecvs.org/download.shtml
o Eclipse
 Es un IDE de programación usado ampliamente para
desarrollo Java. Dispone de plugin para CVS
 http://www.eclipse.org/downloads/
Repositorios

Contamos con 3 repositorios:
o bd  en este repositorio almacenaremos el código de base
de datos y los deltas que generemos.
 Conexión
:pserver:[email protected]:/usr/local/edu/cvs/bd
o interno  aquí pondremos el código de las aplicaciones que
se desarrollan, mantiene o supervisan por personal propio
del servicio.
 Conexión
:pserver:[email protected]:/usr/local/edu/cvs/inte
rno
o externo  esta reservado para proyectos que se desarrollan
fuera de las instalaciones de la consejería y que el
departamento de desarrollo no supervisa. Por tanto se
trataría de proyectos totalmente externalizados.
 Conexión
:pserver:[email protected]:/usr/local/edu/cvs/bd
Repositorio bd


Nivel 1. Nombre del esquema  Dentro de este repositorio
tendremos una carpeta en mayúsculas por cada esquema de
base de datos que usemos.
Nivel 2  Dentro de la carpeta del esquema tendremos una
carpeta por tipo de objeto.
o Packages
o PackageBodies
o Views
o Triggers
o Deltas
 Aquí tendremos tanto las creaciones como las
sucesivas modificaciones del resto de objetos: tablas,
restricciones, índices etc …
 Se creara un fichero con el nombre
NOMBREESQUEMA-VersionActual-VersionNueva.sql
Por ejemplo: CATALOGO-1.0-1.1.sql
Ubicación CVS: interno/recursos/documentacion/guia_desarrollo.doc
Pagina 16 de 29
Región de Murcia
Consejería de Educación, Formación y Empleo
Avda. de La Fama, 15
Secretaría GeneralSecretaría General
Servicio de Gestión Informática

30006 MURCIA
www.carm.es/educacion
En el mismo fichero se puede hacer todas las
modificaciones y creaciones que se deseen.
Es importante resaltar que en los deltas no se
incluye: Paquete, vistas o triggers, ya que estos
están en las carpetas que hemos mencionado
anteriormente.
Modificaciones ALTER (Carpeta Deltas)
Existen objetos que no podemos pasarlos de nuevo enteros como
ocurre con los del apartado anterior ya que se modifican mediante
“Alter “. Por ejemplo una modificación en una tabla.
Crearemos la carpeta “Deltas” dentro de la nivel 1 y aquí
guardaremos un fichero con el nombre: NOMBRE_ESQUEMA-1.01.1.sql, que indica que es el primer delta ejecutado ya que pasa de la
versión 1.0 a la 1.1.
Cambiaremos de versión cuando lleguemos a X.9 o cuando lo
considere el grupo de trabajo al que se pertenezca.
Repositorio interno y externo
Antes de crear un nuevo módulo (proyecto) en este repositorio se
solicitará al departamento de desarrollo que de un nombre al módulo.
En interno y externo, los proyectos tendrán siempre la misma
estructura:
 proyecto
o modulo
 tecnologia (oas, java, …)
 La estructura a partir de este nivel será
diferente según la tecnología. Ver desarrollo
con OAS, JAVA (esta al final del documento).
 documentacion
 manuales
o sql
 Ficheros sql (actualización de datos, carga de datos
....) (formato YYYYMMYY-SS-nombre.sql, donde SS es
un secuencial)
o documentación/requisitosproyecto
 Estos documentos son obligatorios según nuestros
procesos de calidad definidos. Las plantillas las
podemos encontrar en CVS interno
recursos/documentación/calidad
o documentación/resultadosproyecto
Ubicación CVS: interno/recursos/documentacion/guia_desarrollo.doc
Pagina 17 de 29
Región de Murcia
Consejería de Educación, Formación y Empleo
Avda. de La Fama, 15
Secretaría GeneralSecretaría General
Servicio de Gestión Informática
30006 MURCIA
www.carm.es/educacion
Estos documentos son obligatorios según nuestros
procesos de calidad definidos. Las plantillas las
podemos encontrar en CVS interno
recursos/documentación/calidad
o documentación/planificacionproyecto
 Estos documentos son obligatorios según nuestros
procesos de calidad definidos. Las plantillas las
podemos encontrar en CVS interno
recursos/documentación/calidad
o documentación/documentosproyectos
 Estos documentos son obligatorios según nuestros
procesos de calidad definidos. Las plantillas las
podemos encontrar en CVS interno
recursos/documentación/calidad

En cada proyecto puede haber varios módulos, cada uno
desarrollado con una tecnología distinta.
Los nombres de los directorios y ficheros no podrán contener
espacios.
Para cada tecnología, utilizaremos una estructura distinta de
directorios, la estructura de una aplicación OAS no será la misma que
la de una java. En la parte final de este documento se abordan varias
tecnologías tipo, OAS y Java, y se proponen una estructura para el CVS
según este tipo.
Los objetos comunes, como librerías de objetos o código, se
dejarán dentro de interno en el directorio recursos (como si fuera un
proyecto) y dentro de él un directorio por tecnología.
interno / recursos / comun / oas /
interno / recursos / comun / java /
Variables CVS
En los ficheros de texto podemos usar una sería de variables que
son sustituidas en el fichero en el momento de la entrega a CVS. Estas
variables con las siguientes:
Para ficheros de texto, algunas variables se sustituyen al subir a cvs:
$Author$ The login name of the user who checked in the revision.
$Date$ The date and time (UTC) the revision was checked in.
$Header$ A standard header containing the full pathname of the RCS file, the
revision number, the date (UTC), the author, the state, and the locker (if locked).
Files will normally never be locked when you use CVS.
$Id$ Same as `$Header$', except that the RCS filename is without a path.
$Name$ * Tag name used to check out this file.
$Locker$ The login name of the user who locked the revision (empty if not locked,
Ubicación CVS: interno/recursos/documentacion/guia_desarrollo.doc
Pagina 18 de 29
Región de Murcia
Consejería de Educación, Formación y Empleo
Avda. de La Fama, 15
Secretaría GeneralSecretaría General
Servicio de Gestión Informática
30006 MURCIA
www.carm.es/educacion
and thus almost always useless when you are using CVS).
$Log$ The log message supplied during commit, ....
$RCSfile$ The name of the RCS file without a path.
$Revision$ The revision number assigned to the revision.
$Source$ The full pathname of the RCS file.
$State$ The state assigned to the revision. States can be assigned with `cvs admin s'--See admin options.
Cuando subamos un fichero de texto a CVS de tipo SQL, por ejemplo
el spec de un paquete, pondremos en la cabecera del fichero el
siguiente contenido.
/*
* Autor: $Author:$
* Fecha: $Date:$
* Fichero: $Source:$
* Revision: $Revision:$
* Comentario: $Log:$
*/
Entornos
Disponemos de distintos entornos. Algunos de los entornos
disponen solo de base de datos y no de servidor de aplicaciones.
Entorno de desarrollo
Este entorno es donde se desarrollaran todo, incluido proyectos
nuevos como tareas de mantenimiento de proyectos en producción.
La base de datos se llama DESA y su cadena de conexión es:
DESA = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = lorqui-vip.carm.es)(PORT =
1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = totana-vip.carm.es)(PORT = 1521))
(LOAD_BALANCE = yes) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME =
desa.carm.es)))
Disponemos de los siguientes servidores de aplicaciones:
 OAS
o Ip  147.84.65.171
o Puerto 7777
o Nombre  vm-oas-des1-edu.carm.es
 Java
o Consultar el documento CVS interno recursos /
documentación / clustersJava.ods
o Algunos de ellos son:
 JOBSS: 147.84.65.118
 TOMCAT: 147.84.65.160
Para traspasos de PL/SQL usaremos el sqlplus, TOAD o cualquier
otro programa.
Ubicación CVS: interno/recursos/documentacion/guia_desarrollo.doc
Pagina 19 de 29
Región de Murcia
Consejería de Educación, Formación y Empleo
Avda. de La Fama, 15
Secretaría GeneralSecretaría General
Servicio de Gestión Informática
30006 MURCIA
www.carm.es/educacion
Entorno de preproducción o pruebas
Este entorno es para PRUEBAS de los usuarios y pruebas antes
de instalaciones en producción.
La base de datos se llama PRUEBAS y su cadena de conexión es:
PRUEBAS = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (HOST = 147.84.64.158) (PORT
= 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = edupru11)))
Para ejecutar SQL o PLSQL usaremos el sqlplus, TOAD o
cualquier otro programa además de las herramienta de traspaso.
Disponemos de los siguientes servidores de aplicaciones:
 OAS
o Ip  147.84.65.171
o Puerto 7777
o Nombre  vm-oas-des1-edu.carm.es
 Java
o Consultar el documento CVS interno recursos /
documentación / clustersJava.ods
o Algunos de ellos son:
 JOBSS: 147.84.65.118
 TOMCAT: 147.84.65.160
Entorno de producción
Este entorno es el REAL.
La base de datos se llama EDUCA y su cadena de conexión es:
EDUCA = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = aguilas-vip.carm.es)(PORT =
1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = alcazares-vip.carm.es)(PORT = 1521)) (ADDRESS
= (PROTOCOL = TCP)(HOST = ceuti-vip.carm.es)(PORT = 1521)) (ADDRESS = (PROTOCOL =
TCP)(HOST = cieza-vip.carm.es)(PORT = 1521)) (LOAD_BALANCE = yes) (CONNECT_DATA =
(SERVER = SHARED) (SERVICE_NAME = educa.carm.es) (FAILOVER_MODE = (TYPE = SELECT)
(METHOD = BASIC) (RETRIES = 10) (DELAY = 1))))
Para conectarnos a producción usaremos el usuario VISOR,
puesto que la clave de los esquemas NO debe ser desconocida por los
integrantes en el desarrollo de una aplicación.
Disponemos de los siguientes servidores de aplicaciones:
 OAS
o Ip  147.84.65.35 y 147.84.65.34
o Puerto 7777
o Nombre 
 Directo:
 vm-oas-pro1.edu.carm.es
 vm-oas-pro1.edu.carm.es
 Balenceado:
 oasedu.carm.es, puerto 80
o
Ubicación CVS: interno/recursos/documentacion/guia_desarrollo.doc
Pagina 20 de 29
Región de Murcia
Consejería de Educación, Formación y Empleo
Avda. de La Fama, 15
Secretaría GeneralSecretaría General
Servicio de Gestión Informática

30006 MURCIA
www.carm.es/educacion
Java
o Consultar el documento CVS interno recursos /
documentación / clustersJava.ods
Para traspasos de PL/SQL y de código de aplicación usaremos la
aplicación de traspaso de código.
Instalaciones en desarrollo
Para hacer ejecuciones de SQL podemos hacerlo directamente
con el SQLPLUS, TOAD o cualquier otra herramienta similar.
Para hacer instalaciones de aplicaciones, lo que haremos será
copiar nuestra aplicación en el ruta \\vm-oasdes1.edu.carm.es\checkout y dentro de esta en la ruta correspondiente
que será similar a la del cvs.
En la ruta donde tenemos el build.xml, tendremos también un
fichero llamado compilar.bat que al ejecutarlo crea el fichero compilar.
Existe un demonio que esta continuamente buscando directorios
que contenga el fichero build.xml y el fichero compilar. Para cada
directorio que encuentre ejecutará el ant build.xml en ese directorio,
produciéndose la instalación de la aplicación en base a las
instrucciones contenidas en el fichero build.xml.
Instalación de código en pruebas y producción
Motivación
La instalación a producción deben estar siempre supervisados por
el responsable del proyecto. Normalmente este papel lo tendrán
personal propio del servicio.
Se ha diseñado un sistema en el cual se solicitan los ficheros que
se desean traspasar y el encargado lo traspasa dándole a un botón. El
resultado se puede ver en pantalla y llega por correo quien lo solicito.
Esto consigue que alguien que desconozca la aplicación pueda
instalarla en un nuevo servidor sin necesidad de conocer como se
instala, ni cual es la clave de bbdd. Además se guarda el registro de
traspasos realizados.
Aplicación de traspaso
Para hacer traspasos a producción lo haremos con la herramienta
de traspasos:
Ubicación CVS: interno/recursos/documentacion/guia_desarrollo.doc
Pagina 21 de 29
Región de Murcia
Consejería de Educación, Formación y Empleo
Avda. de La Fama, 15
Secretaría GeneralSecretaría General
Servicio de Gestión Informática



30006 MURCIA
www.carm.es/educacion
Desarrollo:
o http://vmoas.des1.edu.carm.es:7777/forms/frmservlet?config=segi
Pruebas:
o http://vmoas.pre1.edu.carm.es:7777/forms/frmservlet?config=segi
Producción:
o http://vm-oaspro1.edu.carm.es:7777/forms/frmservlet?config=segi
o http://vm-oaspro2.edu.carm.es:7777/forms/frmservlet?config=segi
o http://oasedu.carm.es/forms/frmservlet?config=segi
Dentro de la opción de menu Traspasos tenemos las siguientes
opciones: Solicitar traspaso, Realizar traspaso y Consultar Traspaso.
La pantalla de “Solicitar traspaso” tiene el siguiente aspecto:
En esta pantalla para cada solicitud tendremos que rellenar los
siguientes campos:
 Aplicación  Con F9 obtendremos la lista de aplicaciones
sobre las que esta habilitado el traspaso de código. En ella
seleccionaremos la que queremos. De elegir una aplicación
u otra dependerá el usuario de base de datos. con el que se
ejecutar o compilará el fichero.
 Usuario BBDD  Este campo no es editable y se recupera
al completar el campo Aplicación.
 Repositorio  Seleccionaremos el repositorio de CVS donde
se encuentra nuestro fichero.
 Fichero  Se corresponde con la ruta CVS que tiene el
fichero dentro del repositorio seleccionado.
Ubicación CVS: interno/recursos/documentacion/guia_desarrollo.doc
Pagina 22 de 29
Región de Murcia
Consejería de Educación, Formación y Empleo
Avda. de La Fama, 15
Secretaría GeneralSecretaría General
Servicio de Gestión Informática



30006 MURCIA
www.carm.es/educacion
SQL  Indica si el fichero es un SQL por tanto debe
ejecutarse. Si el fichero acaba en “.sql” por defecto se
marcará esta opción.
Forzar  Cuando necesitamos recompilar un formulario
(fmb, jsp, php …) marcaremos esta opción. Esto permite
volver a compilar el fichero aún no habiéndose modificado
en CVS desde el último traspaso.
Comentario  Este campo se emplea para hacer alguna
anotación al responsable de traspasos de esa aplicación
para que sepa el motivo del traspaso. En general se podrá
comentar lo que se vea oportuno.
Traspaso de código PL/SQL (DDL y DML)
Los traspasos se realizan desde la pantalla “Realizar traspaso”
que es idéntica a la anterior.
En ella seleccionaremos los ficheros que queremos traspasar y
pulsaremos el botón Traspasar.
Si se trata de un SQL nos llevara a una pantalla que nos muestra
el código SQL que vamos a traspasar como se puede apreciar en la
siguiente imagen:
Ubicación CVS: interno/recursos/documentacion/guia_desarrollo.doc
Pagina 23 de 29
Región de Murcia
Consejería de Educación, Formación y Empleo
Avda. de La Fama, 15
Secretaría GeneralSecretaría General
Servicio de Gestión Informática
30006 MURCIA
www.carm.es/educacion
Al final de la página hay un botón para aceptar y otro para
cancelar.
Si pulsamos aceptar obtendremos una pantalla como la siguiente:
Ubicación CVS: interno/recursos/documentacion/guia_desarrollo.doc
Pagina 24 de 29
Región de Murcia
Consejería de Educación, Formación y Empleo
Avda. de La Fama, 15
Secretaría GeneralSecretaría General
Servicio de Gestión Informática
30006 MURCIA
www.carm.es/educacion
Podemos observar que al final el resultado se envía al quien
solicito el traspaso.
Importante: Traspasos de DDL
Las operaciones DDL (ALTER, REPLACE…, SPEC de paquetes,
procedimiento, …) pueden producir que se descompilen objetos de
diversos esquemas.
Este tipo de ejecuciones puede producir que se queden objetos
INVALIDOS. Como norma general el solicitante de un DDL debe pedir a
continuación el traspaso del fichero,
 Aplicación: CATALOGO
 Repositorio: interno
 Fichero: recursos/sql/recompilarBD.sql
, que se encarga de recompilar todos los objetos inválidos de la base de
datos.
Traspaso de código aplicación (OAS, PHP,…)
El traspaso de código de aplicación se solicita y realiza de modo
semejante al de los SQL.
El traspaso de código esta basado en “ant”, por tanto para que
una aplicación se pueda traspasar automáticamente será necesario crea
un build.xml.
El build.xml no lo debe crear quien va a hacer la aplicación si no
que lo pedirá al departamento de desarrollo que le ofrecerá alguno de la
Ubicación CVS: interno/recursos/documentacion/guia_desarrollo.doc
Pagina 25 de 29
Región de Murcia
Consejería de Educación, Formación y Empleo
Avda. de La Fama, 15
Secretaría GeneralSecretaría General
Servicio de Gestión Informática
30006 MURCIA
www.carm.es/educacion
plantilla o le construirá uno basándose en la estructura de los
servidores y en colaboración con el departamento de sistemas.
Muestro a continuación un ejemplo del traspaso de una
aplicación:
Desarrollos en OAS
OAS son las siglas de Oracle Aplicatión Server. Es un servidor de
aplicaciones de Oracle, integra un servidor de pantallas, de informes y
aplicaciones j2ee.
Entre las ventajes de OAS se encuentra:
 Desarrollo rápido de aplicaciones mediante un IDE muy
sencillo y rápido.
 Incorpora un servidor de informes y de pantallas.
 El diseñador de pantallas e informes es WYSIWYG, lo
que ves es lo que obtendrás.
 El código es PL/SQL
 La 3 capa se ejecuta en un applet lo que la programación
no de la vista no difiere de cómo se programan las
aplicaciones de escritorio.
Entre las desventajas:
Ubicación CVS: interno/recursos/documentacion/guia_desarrollo.doc
Pagina 26 de 29
Región de Murcia
Consejería de Educación, Formación y Empleo
Avda. de La Fama, 15
Secretaría GeneralSecretaría General
Servicio de Gestión Informática


30006 MURCIA
www.carm.es/educacion
Precio de las licencias del servidor OAS. El IDE es gratis.
Requiere un navegador compatible con java
A grandes rasgos los nuevos proyectos se desarrollaran en OAS
siempre sea posible y el usuario este en intranet o en los centros.
Plantillas y pantallas
Antes de empezar cualquier proyecto en OAS nos haremos con los
siguientes ficheros:






ENTRADA.fmb
o Ruta cvs: interno
recursos/comun/oas/fmb/ENTRADA.fmb
o Esta es la pantalla con la que nos identificaremos
o Recibe como parámetro el código de aplicación de
CONTROLAPLIC
comun.pll
o Ruta cvs: interno recursos/comun/oas/pll/comun.pll
o Funciones comunes
webutil.pll
o Ruta cvs: interno
recursos/comun/oas/pll/webutil.pll
o Necesaria para aplicaciones que se usan recursos de
la maquina cliente: Operaciones con ficheros del
disco duro del cliente, ejecutar comandos del sistema
operativo del cliente, etc...
MENU.fmb
o Ruta cvs: interno
recursos/comun/oas/fmb/MENU.fmb
o Esta pantalla construye un menú según la
información de que existan en CONTROLAPLIC para
la aplicación que recibe como parámetro
PLANTILLA.fmb
o Ruta cvs: interno
recursos/comun/oas/fmb/PLANTILLA.fmb
o Esta pantalla contiene los elementos de los que
heredan el resto de pantallas.
PLANTILLA_DESARROLLO.fmb
o Ruta cvs: interno
recursos/comun/oas/fmb/PLANTILLA_DESARROLL
O.fmb
o Esta pantalla es de la que partiremos cada vez que
queramos hacer una nueva pantalla.
Ubicación CVS: interno/recursos/documentacion/guia_desarrollo.doc
Pagina 27 de 29
Región de Murcia
Consejería de Educación, Formación y Empleo
Avda. de La Fama, 15
Secretaría GeneralSecretaría General
Servicio de Gestión Informática
30006 MURCIA
www.carm.es/educacion
Estructura en CVS
Dentro del modulo del repositorio interno o externo, que nos
asigne el departamento de desarrollo dentro del CVS, crearemos la
siguiente estructura:
 Modulo
o oas  Donde estará la aplicación
 fmb  para las pantallas, archivos *.fmb
 pll  para las librerias, archivos *.pll
 iconos  *.gif, *.jpg
 rdf  son lo informes, archivos *.rdf
 olb  para las librerias *.olb
 mmb  para los menus *.mmb
 build.xml  Es el archivo con las instrucciones de
instalación. Lo proporciona el departamento de
desarrollo
Normas
En la medida de lo posible no pondremos código SQL dentro de los
triggers de un FMB. Pondremos la SQL dentro del paquete P
correspondiente. Por ejemplo, validar el código de provincia usaremos la
función existe del paquete P de la tabla provincia.
Desarrollos en Java
Estructura en CVS
Para las aplicaciones java tendremos:
proyecto / modulo / java / res / css (hojas de estilo)
/ res / img (imágenes)
/ res / iconos (iconos)
/ res / scripts (javascripts)
/ web (directorio principal)
/ web / META-INF
/ web / WEB-INF
/ web / WEB-INF / lib
/ src / es / carm / edu
/ src / es / carm / javato
VPN
Cuando el desarrollo se realiza desde fuera de las instalaciones de
la Consejería será necesario solicitar un VPN. El departamento de
sistemas se encarga solicitar la VPN a la D.G.I
Los requerimientos de la VPN son lo siguientes:
Ubicación CVS: interno/recursos/documentacion/guia_desarrollo.doc
Pagina 28 de 29
Región de Murcia
Consejería de Educación, Formación y Empleo
Avda. de La Fama, 15
Secretaría GeneralSecretaría General
Servicio de Gestión Informática
30006 MURCIA
www.carm.es/educacion
Para desarrollo:
 Base de datos desarrollo
o totana-vip.carm.es 1521 tcp
o lorqui-vip.carm.es 1521 tcp
 CVS
o 147.84.65.19 2401 tcp
 Instalaciones en desarrollo
o 147.84.65.171 445 tcp y udp. Servicio samba
 Servidor de aplicaciones:
o OAS  147.84.65.171 7777 tcp
o JAVA  Consultar
Para pruebas:
 Base de datos pruebas
o 147.84.64.158 1521 tcp
 Instalaciones en pruebas
o 147.84.65.172 7777 tcp
 Servidor de aplicaciones:
o OAS  147.84.65.172 7777 tcp
o JAVA  Consultar
Para producción:
 Base de datos de producción
o aguilas-vip.carm.es 1521 tcp
o alcazares-vip.carm.es 1521 tcp
o ceuti-vip.carm.es 1521 tcp
o cieza-vip.carm.es 1521 tcp
 Solicitud de traspaso a producción
o Nodo1: 147.84.65.35 7777 tcp
o Nodo 2: 147.84.65.34 7777 tcp
o Balanceador: oasedu.carm.es:80
 Servidor de aplicaciones:
o OAS  147.84.65.135 y 34 7777 tcp
o OAS  oasedu.carm.es:80
o JAVA  Consultar
Ubicación CVS: interno/recursos/documentacion/guia_desarrollo.doc
Pagina 29 de 29
Descargar
Anuncio
Anuncio