Servicios Web REST SOAP con ILE-RPG

Tomado de:
http://www.help400.com/asp/scripts/nwart.asp?Num=141&Pag=10&Tip=T

¿Qué son realmente los Servicios Web?

Evaluación del auténtico potencial que se esconde tras la publicidad

Si creyéramos a pie juntillas toda la publicidad que inunda el sector de las tecnologías de la información, ahora mismo todo hombre, mujer y niño del planeta estarían concentrados desarrollando servicios web. La exageración ha llegado a tal punto que una importante emisora de televisión está preparando un reality show basado en los servicios web. Con el título provisional de "Supervivientes: Servicios Web", esta serie enfrenta a dos equipos de programadores que viven juntos en una isla desierta que deben llevar a cabo una serie de complejos juegos de programación.

Vale, lo del programa de televisión es mentira, pero está claro que hay mucho de exageración sobre el asunto de los servicios web. ¿A quién creer? Hay profesionales del mundo de la informática que ven los servicios web como una tecnología innovadora que transformará la forma de desarrollar y desplegar las aplicaciones de las generaciones futuras. Y hay otros que ven los servicios web simplemente como un cuento chino del software que apenas hará impacto en el mundo del desarrollo de aplicaciones.

Al final, la única forma de evaluar el impacto de los servicios web es averiguar quién está desarrollando y desplegando actualmente servicios web en el sector de la informática o piensa hacerlo en breve. Para este fin, la firma de investigación Gartner llevó a cabo dos encuestas en febrero de 2003 para medir la fuerza motriz de los servicios web ahora y en el futuro.

La primera encuesta tuvo como objetivo 50 empresas estadounidenses con ingresos anuales de más de 500 millones de dólares. Por conveniencia, en este artículo la llamaremos "Encuesta 50". Aunque el grupo de encuestados era relativamente pequeño, el tamaño de las empresas en que se centra da una buena idea de lo que las grandes corporaciones piensan sobre los servicios web.

La segunda encuesta se hizo a más de 100 empresas estadounidenses que tienen más de 1.000 empleados y que planean desplegar servicios web en un plazo de 12 a 24 meses. A ésta la llamaremos "Encuesta 100". Obviamente, este grupo de encuestados está sesgado puesto que pretenden desplegar servicios web; aún así, la encuesta revela datos muy interesantes.

Fíjese que ambos estudios se centran en los Estados Unidos. En realidad, en otros países tienen otros niveles de interés por los servicios web y ritmos de despliegue diferentes. Por lo tanto, deberá ser cuidadoso a la hora de extrapolar los resultados de las encuestas en el mercado mundial.

Servicios web por su nombre

La primera complicación que uno se suele encontrar cuando investiga los proyectos de servicios web es que cada uno tiene una interpretación distinta de lo que son los "servicios web". Por ejemplo, algunas personas ven los servicios web simplemente como la preparación de las aplicaciones para poder utilizar XML. Para otros, se trata de poner unas cuantas importaciones y exportaciones de XML delante de un viejo programa escrito en RPG del iSeries y voilà, ya tenemos servicios web.

La definición más habitual de servicios web en el sector (y la que adoptaremos aquí) es la que dice que para que una aplicación pueda calificarse como un componente de servicios web debe utilizar una o varias de las tecnologías siguientes: Protocolo simple de acceso a objetos (SOAP o Simple Object Access Protocol), Lenguaje de descripción de servicios web (WSDL o Web Services Description Language) y Descripción, descubrimiento e integración universales (UDDI o Universal Description, Discovery and Integration). El uso de XML está implícito en todos esos estándares.

Esta idea de igualar a XML con los servicios web aparece claramente en las dos encuestas de Gartner. En la "Encuesta 50", el 86% de los encuestados respondieron que en sus proyectos de servicios web se utilizaba XML, pero sólo el 31% señaló que se utilizaba SOAP, el 14% UDDI y menos del 10% WDSL.

En la "Encuesta 100" (que, como ya hemos mencionado, se basa en empresas que dicen tener en marcha proyectos de servicios web), los resultados son parecidos. Aquí, el 75% de los encuestados indica que utiliza XML, pero sólo el 31% dice que usa SOAP. En el caso tanto de WSDL como UDDI los porcentajes que se obtienen son menores.

La conclusión es que el énfasis puesto por el sector en XML como espina dorsal de los servicios web ha desdibujado la definición de servicios web en las mentes de muchos informáticos. Las organizaciones pueden creer que están metidas de lleno en proyectos de servicios web, pero si hemos de ser rigurosos, lo cierto es que no es así.

Tapar huecos con servicios web

El plan maestro de los servicios web consiste en ofrecer un marco para desplegar tanto aplicaciones dentro de una empresa (intraempresa) como aplicaciones que abarcan varias empresas (interempresas). La aplicación desplegada puede estar constituida por nuevos componentes de software escritos siguiendo los estándares de los servicios web y por componentes de software antiguos adaptados a los servicios web.

De acuerdo con la "Encuesta 100", el 54% de los encuestados prevén utilizar los servicios web para integrar aplicaciones tanto dentro de la empresa (intraempresa) como con socios o clientes (interempresas) en el plazo de 12 meses. Durante el mismo tiempo, el 39% prevé utilizar los servicios web solamente dentro de la empresa. Cuando el periodo se alarga a 24 meses, el porcentaje de utilización interempresas aumenta al 65% y el porcentaje de utilización intraempresas baja al 23%.

La "Encuesta 50" muestra un panorama algo diferente. El 48% de los encuestados están interesados en un uso intraempresa y el 41% interempresas. La diferencia no es demasiado sorprendente puesto que los encuestados en la "Encuesta 100" están dedicándose activamente a desarrollar proyectos de servicios web, mientras que los de la "Encuesta 50" no necesariamente tienen el mismo nivel de implicación.

Los resultados sugieren que las empresas primero desplegarán los servicios web para resolver la integración interna de las aplicaciones y las necesidades de aplicaciones nuevas y que más tarde los extenderán fuera de la empresa. Esto es válido tanto para los proyectos intraempresa de la "Encuesta 100" como para los de la "Encuesta 50", en la que se muestra un interés mucho mayor por los proyectos intraempresa.

El factor del proveedor

En la visión que se tiene de los servicios web, los componentes de las aplicaciones pueden interconectarse sea cual sea el lenguaje en que se hayan escrito o la plataforma en que se ejecuten. Sin embargo, la realidad es que los servicios web están implementados en plataformas, servidores de aplicaciones, lenguajes e incluso productos de bases de datos concretos. Por ejemplo, .NET de Microsoft tiene sus raíces en la plataforma Windows, mientras que J2EE tiene propensión por Unix (en honor a la verdad, J2EE puede ejecutarse en Windows y en otras plataformas, pero la mayoría de las implementaciones son para Unix o Linux).

¿Cuáles son las arquitecturas y productos dominantes en el mercado? En la "Encuesta 50", el 48% de los encuestados señalaba que J2EE iba a ser su arquitectura principal para los servicios web y el 39% apuntaba a .NET (el 13% restante no lo sabía). Sin embargo, observe que a los encuestados sólo se les permitía escoger su arquitectura "principal". De modo que las empresas que prevén desplegar ambas arquitecturas estaban limitadas a dar una sola respuesta.

La "Encuesta 100" revela más cosas sobre el despliegue de varias arquitecturas ya que permite a los encuestados seleccionar múltiples respuestas. Aunque dicha encuesta no hace la pregunta sobre la arquitectura, si que lo hace sobre los servidores de aplicaciones que se están utilizando actualmente para los proyectos de servicios web y los que están previstos instalar. En este estudio, algo más del 50% de los encuestados responde que .NET de Microsoft será el servidor de aplicaciones para los proyectos actuales y futuros.

Aunque .NET obtiene muy buenos resultados, los de los servidores de aplicaciones J2EE tampoco son malos. En el caso de los proyectos de servicios web actuales, Apache, 9iAS de Oracle y WebSphere Application Server de IBM obtienen cada uno entre el 20% y el 25%. Cuando se trata de los proyectos futuros, .NET obtiene el mismo resultado, pero Apache, 9iAS de Oracle y WebSphere Application Server de IBM suben hasta el 25%-30%.

Observe también que la competición entre los proveedores acaba de empezar; es demasiado pronto para declarar ganadores y perdedores. Por lo tanto, las empresas deben potenciar las relaciones con sus proveedores o asegurarse de que un nuevo acuerdo de colaboración ofrece la mejor adaptación tecnológica posible y que es financieramente viable (es decir, que la recuperación de la inversión es a corto plazo). La encuesta también indica que las empresas deben estar preparadas para desplegar ambas arquitecturas, J2EE y .NET; hoy por hoy no hay una arquitectura todo-en-uno.

Quedarse con lo que nos interesa

Los resultados de cualquier encuesta siempre deben valorarse con cautela y debemos someterlos a nuestro propio punto de vista. Sin embargo, las encuestas permiten tomarle el pulso al sector de forma razonable y pueden utilizarse como norma para ver cómo se compara nuestra empresa con las demás. En términos de esa comparación, estas son las cuestiones que hay que hacerse para comparar nuestra empresa con la media.

1. Los servicios web no se han entendido bien. ¿Cuál es la definición de servicios web que se utiliza en su trabajo y cómo se compara con las definiciones del sector?

2. XML es una piedra angular del futuro. Tanto si utiliza XML en un contexto de servicios web "real" como si no, XML está emergiendo sin duda como una importante interfaz para la integración de aplicaciones. ¿Cuál es el nivel de conocimiento de XML que se tiene en su organización y qué proyectos orientados hacia XML se han iniciado o se prevé iniciar?

3. Empezar internamente y luego hacerlo externamente. Si su empresa ha iniciado algún proyecto de servicios web o únicamente de XML, ¿estos proyectos se aplican interna o externamente? Los estudios demuestran que la mayoría de las empresas empiezan internamente, para ganar experiencia, y luego amplían el ámbito de sus despliegues.

4. Sea receptivo a las opciones del proveedor. En muchos casos, las empresas no son capaces de estandarizarse en una sola arquitectura de servicios web o en un solo servidor de aplicaciones. ¿Cuáles son sus proveedores de plataformas estratégicos? ¿Cuáles son sus proveedores de servidores de aplicaciones estratégicos? Las respuestas a estas preguntas le indicarán con toda probabilidad cuáles son las arquitecturas y productos más importantes para usted.

¿Por qué no ahora?

Si su empresa está preparando sus aplicaciones para que puedan utilizar XML o está poniendo en marcha proyectos de servicios web de gran alcance, obviamente trabaja en una gran compañía. Si no, puede que trabaje en una empresa que tiene una posición más conservadora sobre las nuevas tecnologías o que alguien del departamento de informática se ha dormido en los laureles. En este caso, puede que éste sea un buen momento para hacer una llamada de advertencia. Los servicios web interempresa están creciendo y, tarde o temprano, se cruzarán en el camino de su empresa. ¿Para qué esperar si puede empezar a prepararse ya?

Sean Chandler es un consultor con más de 20 años de experiencia real. Conoce un buen número de sistemas: iSeries, Windows, NetWare, OpenVMS, Unix y Linux. Además, está más familiarizado de lo que quisiera con los entornos de middleware y de servidores de aplicaciones.

http://www.mail-archive.com/forum.help400@combios.es/msg13096.html

Servicios Web con ILE-RPG y SOAP

alex martinez

Wed, 24 Mar 2004 01:56:50 -0800

Hola a todos:

Despues de leer el artículo publicado en help400 el mes pasado sobre los

servicios web

http://www.help400.com/asp/scripts/nwart.asp?Num=141&Pag=10&Tip=T, me

preguntaba si era posible desarrollar un cliente de servicio web, utilizando

ÚNICAMENTE ILE-RPG.

Buscando con Google vi que hay cientos de servicios web y que incluso Google

tiene su propio servicio web que permite mediante mensajes SOAP (basado en

XML) realizar consultas desde nuestros programas en nuestro lenguaje de

programacion preferido.

Me descargé los ejemplos que proporciona Google y por supuesto, entre estos

no se incluía ninguno en ILE-RPG. Así que decidí desarrollar un programa de

un servicio web en RPG.

Para ello es necesario la libreria de Scott Klement

http://www.scottklement.com/httpapi/

y crear una cuenta en Google para obtener una clave de licencia (todo

gratis). http://www.google.com/apis/

La libreria HTTPLIB de Scott Klement proporciona toda la comunicacion con

Sockets entre sistemas y porporciona funciones para los métodos GET y POST

de HTTP, ya que SOAP realiza su comunicacion a traves de HTTP.

La clave que proporciona Google permite la identificacion de nuestras

peticiones y nos limita a realizar hasta 1000 consultas diarias.

Si estais interesados podeis descargar los fuentes que he dejado en mi web.

http://www.ajut400.com/ajut400/google1.rpgle

http://www.ajut400.com/ajut400/google.cmd400

Tomado de:

http://sites.google.com/site/ajut400/web-services-con-ile-rpg

Web Services con ILE-RPG

Implementar un servicio web en i5 (System i o AS400 de toda la vida) con V5R4 consiste en:

* Un programa ILE-RPG de cálculo de costes de envio (descargar y compilar el programa ILE-RPG del archivo shipcost.zip adjunto).

* Convertir nuestro programa RPG en un Web service con un asistente de 8 pasos, que se completa habitualmente en ménos de 1 minuto.

* Realizar pruebas con Web Services Explorer, tambien integrado en i5.

No requiere ninguna herramienta para PC; únicamente un navegador.

Instrucciones para instalar libreria de Sockets
Tomado de:
http://www.scottklement.com/httpapi/httpapi_savf.html


_______________________________________________________________________________
Otra fuente interesante:

Consumir un web service desde un programa ILE RPG en Iseries AS/400

  

CONSUMIR UN WEB SERVICE DESDE UN PROGRAMA RPG/400

 Hace unos días me encargaron un proyecto en una entidad donde el 100 % de su software en producción está desarrollado con Genexus, en la plataforma AS/400 V5R4M00 procesando programas generados en RPG nativo. El proyecto implicaba conectarse desde un programa RPG a un web service externo, obtener datos de validación, confirmar la operación en el web service actualizando su base de datos externa y finalmente registrar los datos en la base de datos Iseries.

Genexus no soporta ese tipo de operaciones en la plataforma AS/400, por lo que tuve que buscar alternativas a mano, aunque Google no fue de demasiada ayuda, ya que no hay demasiada experiencia sobre este tema. Supongo que se considera un poco pasado de moda el RPG/400.

RPG es bastante áspero para comunicarse con otras plataformas on-line, salvo cuando fija las reglas. No me servía APPC (me pareció demasiado complicado organizar eso), ni tampoco el ODBC porque las transacciones se originaban en el ambiente nativo. Si el caso hubiera sido el inverso (generar transacciones que afecten la base de datos nativa) la solución era trivial. Una opción razonable era usar las DTAQ, que pueden ser accedidas desde ambiente nativo y Windows, pero me complicó tener una cantidad no definida de usuarios concurrentes. El indexado de las DTAQ es limitado. Por otra parte, me obligaba a tener un servidor adicional activo para poder interactuar con el web service externo en ambiente PC, con los problemas que esto conlleva (de mantenimiento y control sobre todo).

Buscando por la red, encontré una biblioteca OpenSource para administrar sockets y generar HTTP desde RPG/400, de un gordito llamado Scott Klement (http://www.scottklement.com/), bajé todo lo que hay en el sitio y me puse a estudiar. No soy un experto en ILE RPG ni mucho menos,hace muuuucho tiempo que no programo manualmente, así que me costó bastante el tema.

Para preparar el escenario, creé un Web Service en mi localhost con Genexus X WEB muy simple, solamente recibe un tipo y número de documento y devuelve el nombre del cliente desde una base de datos MySQL. Hice un work panel cliente en genexus 9.0 WIN para probar el funcionamiento desde otra pc y todo funcionó sin problemas. Para ver bien el Web Service bajé un software llamado SOAPUI (open source) de http://www.soapui.org/ que permite testear y observar Web Services que es bastante bueno.

Usando su LIBHTTP/QRPGLESRC/EXAMPLE18 como modelo,empecé a meter mano. Primer problema, hay que armar el XML de envío a mano y para eso me fue útil la estructura del Soapui. Segundo problema, el mensaje que se recibe es XML y tuve que parsearlo a mano. (Prueba y error) * n veces más no pude hacer que funcionara con mi web service el parsing del modelo.

Dándole vueltas al tema me topé con un sitio (Isockets.com) de Bob Cozzi, que tiene una biblioteca de rutinas que manejan los sockets del AS/400. Bajé la biblioteca, la instalé en mi equipo y empecé a probar. En definitiva me pareció mucho más fácil de usar y una ayuda bastante más detallada. Para la versión V5R4M0 es imprescindible tener aplicadas algunas PTF’s, principalmente la MF40520 (importante porque el source sí se cobra).

El proceso de comunicación, partiendo del modelo que hay en la biblioteca, fue bastante simple. Igualmente hay que armar a mano el xml de envío (para eso usé SoapUI). En teoría el HttpParse se encarga de desarmar el xml de recepción pero no logré hacerlo funcionar, al igual que el XML_INTO del ILE RPG. Me parece que alguno de los datos adicionales (el namespace u otro) que el web service generado por Genexus envía no son entendibles por el XML-INTO o por el DAX. Tampoco me puse a averiguar demasiado porque usando %SUBST y %SCAN en un minuto se “pela” el xml, dejando en variables los datos reales que quiero.

También hay herramientas en http://www.tools400.de/English/Freeware/WSDL2RPG/wsdl2rpg.html, pero ya tenía el asado listo, así que simplemente lo miré un poco. Parece bueno pero son solo las herramientas sin demasiados ejemplos de uso.

En resumen, los programas RPG de la aplicación hechos en Genexus llaman con parámetros a un pequeño programa de comunicaciones también ILE RPG, que mediante HTTP accede al web service y devuelve los datos solicitados. No es necesario usar absolutamente nada de los servidores locales, salvo el browser  ni hacer programas java. Creo que quedó una solución elegante.

El tema que me queda pendiente es el SSL, porque los tipos del web service externo usan un certificado propio (no Verisign ni los comunes) y me obligan a configurar mi AS/400 para manejar certificados digitales. Aún no lo pude probar pero parece ser alguito complicado. Si les toca lo mismo, vean el manual de Security Digital Certificate Manager de IBM como para empezar.

Algo de bibliografía para buscar, si lo necesitan es:

http://www.scottklement.com/

http://www.recursos-as400.com/documentos.shtml

http://www-01.ibm.com/support/docview.wss?rs=959&uid=swg27009770

http://www.ibm.com/developerworks/webservices/library/ws-as400/index.html

http://systeminetwork.com/article/rpg-consuming-web-services-httpapi-and-soapui

http://www.isockets.net/

http://www.soapui.org/

http://www.tools400.de/English/Freeware/WSDL2RPG/wsdl2rpg.html

http://www.rpg-xml.com/ - Parece completito pero es pago, así que ni bajé el trial, pero...

Descarga Sockets para el AS400

Videos de Drupal - Para descargar

11 Razones para crear su Sitio Web con el CMS Drupal

Curva de aprendizaje de Drupal

27 Características de DRUPAL


Publicar una entrada de blog con una noticia vista en el agregador de noticias externas


Aulablog labs presenta Planeta de Blogs



Video Tutoriales


Video Tutorial – El Editor De Contenidos de Drupal

Video Tutorial Cómo crear una página en Drupal

Video Drupal. Cómo Crear Nuevos Bloques


Drupal Gardens de Acquia

Instalación y administración de Drupal [Parte 1]


Personalizar el formulario de login en Drupal 6

Archivo para la Categoria: Videos Drupal

01.- Video 01
02.- Video 02
03.- Video 03
04.- Video 04
05.- Video 05
06.- Video 06
07.- Video 07
08.- Video 08
09.- Video 09
10.- Video 10
11.- Video 11
12.- Video 12
13.- Video 13
14.- Video 14
15.- Video 15
16.- Video 16
17.- Video 17
18.- Video 18
19.- Video 19
20.- Video 20
21.- Video 21
22.- Video 22
23.- Video 23
24.- Video 24
25.- Video 25
26.- Video 26
28.- Video 28

Montando un sitio web con Drupal (Video)

Tomado de:
http://programacionlibre.blogspot.com/2009/08/montando-un-sitio-web-con-drupal-video.html


viernes, agosto 28, 2009
Montando un sitio web con Drupal (Video)
Montando un sitio web con Drupal - sexta parte

Instalar un módulo: Flashvideo

Crear un tipo de contenido exclusivo para videos institucionales

Me he guiado por [1], pero con pequeñas variaciones, que describo desde el principio. Haré una mala traducción, ya que [1] por estar publicado en drupal.org le da carácter de oficial.

Permite subir vídeos a su sitio web e incorporarlo a cualquier contenido existente en la misma

Manual para el uso del módulo de FlashVideo para Drupal.

Pasos a seguir:

1. Descargar del sitio de Drupal el módulo (http://drupal.org/project/flashvideo)
2. Una vez descargado, instalelo normalmente copiando el módulo en la carpeta de módulos de su sitio
3. Luego, en el sitio debe activar el módulo
4. El módulo, una vez instalado, se verá en la lista de módulos en: Administrar -> Configuración del sitio, c omo se muestra en la imagen 1
5. La configuración del entorno del módulo, quedará más o menos como se ve en la imagen 2 (muestra unas notas importantes sobre los parámetros a ser fijados en php.ini, los actuales de sus sistema y los recomendados) y la imagen 3 (muestra los tipos de nodos existentes en su sistema, donde podrá ingresar a cada uno para ver el estado y opearción de cada uno. Esto es, que puede publicar videos en cualquier módulo, basta con configurar el tipo de contenido y habilitar el módulo, tal como se muestra en la imagen 4)
6. Si se desea incrustar el vídeo en un tipo de contenido, seleccione el tipo de contenido y sus operaciones estraán marcados para este tipo de nodo. El procedimiento será el mismo para cualquier tipo de contenido. En las imágenes se muestra como la configuración de estos campos y opciones:
7. Una vez configurado el módulo, guardar los cambios.
8. Puede ocurrir un error semejante al mostrado en la imágen, que se resolverá descargando los controladores de S3 en [4]
9. Descargar y extraer la carpeta. Ésta se guarda en el directorio módulos -> FlashVideo -> drivers. Luego, volver a la página de configuración y veria como el error a desaparecido.
10. Para este módulo se pueden utilizar varios tipos reproductores de medios swf. Dos de los más utilizados, son JW Player and the Dash Media Player los cuales puedes descargar en [2]. Ahí mismo hay unas instrucciones para su instalación, las cuales también comentaré acá según mi experiencia.
11. En mi caso, he decidido el JW Player, así que será ese el que comentaré acá cómo me ha ido... Descargado y descomprimido, hay un archivo lamado player-viral.swf el cual he renombrado a Player.swf. Éste último y el swfobject.js los he copiado en el directorio raíz de mi instalación de drupal. En [2] sugiere que se copien en el directorio files, pero mirando los logs de apache me decía que no los encontraba en el directorio padre, así que los coloqué ahí. El resto de pasos sugeridos en [2] no me han sido útiles, así que los he obviado.
12. Finalmente, para poder verlo, he seguido lo que dice [3].
13. El último paso, tal como dice en [1], para poder ver el vídeo insertado en el sitio, es ejecutar el cron, esto se hace de la siguiente manera, vaya a Administrar / Informe de situación y tareas de mantenimiento de cron / ejecutar cron manualmente, lo que necesita saber que cada vez cree una página para integrar un video se necesita ejecutar el cron, una vez hecho esto se puede ver el vídeo incrustado.

Primeros pasos con Drupal

Tomado de:
http://drupal.org.es/node/4530

Instalar Drupal 6.x

Si requieren revisar videos sobre Drupal, pueden hacerlo en esta URL, cuando ingrese en Buscar asignan DRUPAL y podra revisar la cantidad de videos disponibles aqui

Manual para instalar Drupal 6.x (6.16) paso a paso.

Componentes claves de Drupal 6.x..

I- Para instalar Drupal en modo local.
Necesita instalar Apache, MySQL y PHP en el PC (computadora, ordenador). Esto puede hacerlo en una sola instalación utilizando los paquetes ya preparados y configurados como:
AppServ,
XAMPP,
WAMP,
EasyPHP

Se recomienda siempre revisar los requisitos de Drupal antes de proceder con la Instalacion respectiva, sobre todo las versiones de:
PHP , Apache y MySql, revisar requerimientos.

Antes de iniciar el proceso de instalacion se recomienda leer este mensaje:

Si es necesario acudir por consultas se puede ingresar a la pagina de Drupal en español http://drupal.org.es/foros, ahi podrá encontrar mucha informacion sobre los niveles de error que posiblemente se origen como resultado del proceso de instalacion.


II- Para instalar Drupal en sitio remoto.
El servidor externo debe tener creada una Base de Datos y usted debe saber el Nombre de la Base de Datos, Nombre de Usuario y Contraseña (de no saberlo necesita llamar a su proveedor de hosting y pedirle esa información).

III- Para realizar modificaciones y copias de seguridad de su base de datos, necesita un administrador de Bases de Datos (su proveedor de hosting le proporcionara una dirección con el administrador utilizado en el servidor externo). En modo local puede utilizar PHPMyAdmin (los paquetes preparados y antes mencionados ya lo incluyen).

IV- Para subir archivos a su sitio remoto (servidor externo) necesita instalar un cliente de servidor FTP, en este caso Filezilla

Nota: Es necesario saber el nombre de su Servidor FTP, Usuario y Contraseña.
De no saberlo necesita llamar a su proveedor de hosting y pedirle esa información).

V- En ocasiones es necesario editar archivos de configuración, puede utilizar Notepad++.
Preparar Instalación de Drupal 6.x en Español

1- Descargue versión más reciente de Drupal 6 . Lo cual creara un archivo llamado (drupal-6.x.tar.gz).

2- Descomprima el archivo descargado en algún directorio de su PC. Lo cual creara una carpeta llamada (drupal-6.x) que contiene las carpetas y archivos de instalación de Drupal.

3- Descargue versión más reciente de la traducción para Drupal 6 (en este caso 6.x-1.0). Lo cual creara un archivo llamado (es-6.x-1.0.tar.gz).

4- Descomprima el archivo descargado en algún directorio de su PC. Lo cual creara varias carpetas y archivos txt.

5- Copie los archivos y carpetas de traducción dentro de la carpeta principal de Drupal (drupal-6.x) y reemplace los archivos originales.
Subir archivos de Drupal 6.x al Servidor

6- Para instalar Drupal en sitio remoto. A través de Filezilla suba todos los archivos existentes dentro de la carpeta (drupal-6.x) a la carpeta raíz de su sitio remoto (servidor externo).

Nota: De momento es la forma mas fácil de instalar Drupal, si renombra la carpeta o la sube como tal (drupal-6.x), tendrá que modificar la configuración y re direccionar la instalación de drupal (proceso más laborioso que no he logrado comprender del todo).

Para instalar Drupal en modo local. Copie todos los archivos existentes dentro de la carpeta (drupal-6.x) a la carpeta raíz de su servidor local Ej. carpeta www donde se instalo EasyPHP.

Nota: Si utilizó otro paquete de instalación en modo local, vea la ayuda para saber cual es su carpeta raíz.

7- Acceda a la carpeta que contiene Drupal escribiendo la dirección de su sitio en la barra de exploración de su navegador web, ejemplo:

En sitio remoto: http://www.nombremisitio.com.
En modo local: http://localhost

En su navegador, pulse la opción Ir a la URL (para Actualizar).
Iniciar el proceso de Instalación

8-Se mostrara la página Choose language (selección de Idioma).
Marque la opción Install Drupal in Spanish.
Pulse el botón Select language.

9- Se mostrara la página Problema de requerimientos (se muestran los errores existentes).
Nota: Para poder instalar drupal, primero debe resolver los problemas detectados:

Mensajes de error conocidos:
Error 1: The Drupal installer requires that you create a settings file as part of the installation process. Copy the ./sites/default/default.settings.php file to ./sites/default/settings.php.
Posible solución: Copie el archivo ./sites/default/default.settings.php y renómbrelo como ./sites/default/settings.php.
Vuelva a la página de errores de drupal (explorador web) y pulse el enlace try again (prueba de nuevo).

Error 2: The Drupal installer requires that you create ./sites/default/settings.php as part of the installation process, and then make it writable. If you are unsure how to grant file permissions, please consult the on-line handbook.
Posible solución: Cree un archivo nuevo llamado settings.php (déjelo en blanco), y súbalo al directorio ./sites/default/ de su instalación de drupal.
Vuelva a la página de errores de drupal (explorador web) y pulse el enlace try again (prueba de nuevo).

Error 3: Error de permisos de escritura en directorios/archivos de drupal.
Posible solución: Cambiar permisos de escritura de sites/default o archivos indicados en error.
En sitio remoto: A través de Filezilla puede cambiar los atributos haciendo clic con el botón derecho sobre el directorio default dentro del directorio sites (sites/default) y seleccionando Atributos de archivo... Active todos los atributos de Escribir y Ejecutar. Pulse el botón Aceptar. (recuerde la configuración actual, mas adelante necesitara volver a restaurarlos) Ej: solo se encuentran activados todos los permisos de Leer.
En modo local: puede cambiar los atributos haciendo clic con el botón derecho sobre el directorio sites/default y seleccionando Propiedades/Desactivar el Atributo: Sólo lectura pulse el botón Aplicar, Aceptar.
Vuelva a la página de errores de drupal (explorador web) y pulse el enlace try again (prueba de nuevo).

Error 4: Change file permissions so that it is writable by the web server. If you are unsure how to grant file permissions, please consult the on-line handbook.
Posible solución: Cambiar permisos de escritura de sites/default o archivos indicados en error.
En sitio remoto: A través de Filezilla puede cambiar los atributos haciendo clic con el botón derecho sobre el directorio default dentro del directorio sites (sites/default) y seleccionando Atributos de archivo... Active todos los atributos de Escribir y Ejecutar. Pulse el botón Aceptar. (recuerde la configuración actual, mas adelante necesitara volver a restaurarlos) Ej: solo se encuentran activados todos los permisos de Leer.
En modo local: puede cambiar los atributos haciendo clic con el botón derecho sobre el directorio sites/default y seleccionando Propiedades/Desactivar el Atributo: Sólo lectura pulse el botón Aplicar, Aceptar.
Vuelva a la página de errores de drupal (explorador web) y pulse el enlace try again (prueba de nuevo).

Error 5: El directorio sites/default/files no existe, ya que no se ha creado automáticamente.
Posible solución: Crear el directorio files manualmente.
En sitio remoto: A través de FileZilla, seleccione la carpeta sites/default. Haga clic con el botón derecho en el panel de Archivos remotos, y seleccione la opción Crear directorio con lo que se creara una carpeta llamada Nueva carpeta, pulse el botón Aceptar.
- Seleccione la Nueva carpeta y haga clic con el botón derecho del ratón, seleccione la opción Renombrar y escriba files puede hacer clic en otro lugar para ver el cambio.
Cambie los permisos de escritura del directorio files a Escribir.
En modo local: puede crear una carpeta directamente dentro del directorio sites/default.
Vuelva a la página de errores de drupal (explorador web) y pulse el enlace try again (prueba de nuevo).

Error 6: Solicita la instalación de la extensión de PHP g2.
Posible solución: Forma parte del lenguaje PHP, depende del uso local o remoto.
En sitio remoto: Contacte con su proveedor de hosting para resolverlo ya que se trata de una extensión de PHP.
En modo local: puede solicitar la instalación de la extensión de PHP g2, si instalo EasyPHP como paquete de servidor local. (Pulse el icono (e) de la barra de tareas, a continuación clic sobre Configuración/Extensiones PHP y se mostrara una ventana que muestra todas las extensiones disponibles para esa versión de php. Seleccione la que desea instalar y haga clic sobre Aplicar).
Vuelva a la página de errores de drupal (explorador web) y pulse el enlace try again (prueba de nuevo).

10- Se mostrara la página de Configuración de la base de datos.
Esta página se compone de dos apartados:

Opciones básicas: contiene tres campos donde debe insertar la información de su BD.

Database name (Nombre de la base de datos):
proporcionado_por_proveedor (mysql en modo local)

Database name (Usuario de la base de datos):
proporcionado_por_proveedor (root en modo local)

Database password (Contraseña de la base de datos):
proporcionado_por_proveedor (ninguna en modo local)

Pulse Opciones avanzadas: contiene tres campos el segundo es detectado automáticamente.

Database host (Servidor de la base de datos):
proporcionado_por_proveedor (localhost en modo local)

Database port (Puerto de la base de datos):
ninguna (ninguna en modo local)

Table prefix (Prefijo de las tablas):
escriba drupal_ (drupal_ en modo local)

Nota: Si esta instalando Drupal en un sitio remoto (servidor externo) la información acerca de su BD, debe proporcionársela su proveedor de hosting.
Si esta instalando Drupal en modo local y utiliza EasyPHP como servidor local. El nombre de la base de datos es (mysql) y el usuario (root) sin contraseña. (Esto es valido para los usuarios de Xampp).

El prefijo de las tablas drupal_ (drupal seguido de guión bajo) se utiliza para diferenciar las tablas que pertenecen a drupal y así poder utilizar varias tablas en la misma base de datos. (ej. cuando crea una BD para un foro).

Al completar la información Pulse el botón Save and continue (Guardar y continuar).

11- Se mostrara las páginas del proceso de Instalación de Drupal e Importación de traducción del interfaz.
Espere...

12- Se mostrara la página de Configurar sitio.

Observe el mensaje color verde indicando: Todos los cambios necesarios a ./sites/default y ./sites/default/settings.php han sido realizados. Se han configurado como solo-lectura por seguridad.

Nota: Si no se configuran como solo lectura tendrá que hacerlo manualmente a través de Filezilla.

Esta página se compone de tres apartados:

Información del sitio: proporcione la información solicitada para su sitio.

Site name (Nombre del sitio):
Nombre que queremos dar a nuestro sitio (localhost en modo local)

Site e-mail address (e-mail del sitio):
Correo electrónico del sitio (me@localhost.com en modo local o cualquiera)

Nota: para saber el correo de su sitio remoto, llame a su proveedor de hosting si contrato e-mail.

Cuenta del administrador: En el futuro con esta información accederá al sitio como administrador (será el user1) y al que se le enviara información.

Username (Nombre de usuario):
Nombre con el que accederá a su sitio como administrador (cualquiera en modo local)

E-mail address (Dirección de correo):
Su correo electrónico al que se le enviara la clave de acceso (me@localhost.com en modo local)

Password (Contraseña):
Una contraseña con más de seis dígitos (pueden ser letras y números)

Confirm password (Confirmar contraseña):
La misma contraseña insertada anteriormente

Server settings (Configuración del servidor): Define información sobre el control en su servidor.
Zona horaria predefinida:
Defina su zona horaria, si la predefinida es correcta déjela como esta.

Clean URLs (URLs limpios):
Vea si la configuración de su sistema soporta esa función en el recuadro.

Update notifications (Actualizar notificaciones):
Sirve para comprobar si hay actualizaciones sobre drupal, déjela como esta.

Al completar la información Pulse el botón Save and continue (Guardar y continuar).

13- Se mostrara la página del proceso de Importación de traducción del interfaz.
Espere...
Nota: Esta página no se muestra si instala Drupal en ingles.

14- Se mostrara la página de Instalación de Drupal completa, indicando que el proceso de instalación fue exitoso.
Pulse el enlace your new site (visitar su nuevo sitio).

Mensajes de error conocidos en modo local:
Error 1: warning: mail(): Failed to connect to mailserver at "localhost" port 25, verify your "SMTP" and "smtp_port" setting in php.ini or use ini_set() in c:\archivos de programa\easyphp1-8\www\includes\mail.inc on line 193. Unable to send e-mail. Please contact the site admin, if the problem persists.
Posible solución: El mensaje indica que es imposible enviar email al administrador, continúe la instalación.
Pulse el enlace your new site (visitar su nuevo sitio).

15- Se mostrara la página de Bienvenido a su nuevo sitio web con Drupal.
Nota: Esta página desaparece al crear su primera página de contenido (node).

Primera configuración de Drupal.
16- En la página de Bienvenida de su nuevo sitio pulse el enlace administration section (sección de administración).

17- Seleccione Administer > Reports > Status report (informe de estado).

Mensajes de error conocidos en modo local:
Error 1: GD library Not installed
The GD library for PHP is missing or outdated. Please check the PHP image documentation for information on how to correct this.
Posible solución: Forma parte del lenguaje PHP, depende del uso local o remoto.
En sitio remoto: Contacte con su proveedor de hosting para resolverlo ya que se trata de una extensión de PHP.
En modo local: puede solicitar la instalación de la extensión de PHP g2, si instalo EasyPHP como paquete de servidor local. (con el botón derecho seleccione el icono (e) de la barra de tareas, a continuación clic sobre Configuración/Extensiones PHP y se mostrara una ventana que muestra todas las extensiones disponibles para esa versión de php. Seleccione la que desea instalar (php_gd2) y haga clic sobre Aplicar).
Vuelva a la página de Status report (explorador web) y actualícela.

Error 2: Archivo de configuración No protegido
The directory sites/default is not protected from modifications and poses a security risk. You must change the directory's permissions to be non-writable.
Posible solución: Vuelva los permisos de escritura de las carpetas sites/default a su estado original.
En sitio remoto a través de Filezilla puede cambiar los atributos haciendo clic con el botón derecho sobre el directorio sites/default y seleccionando Atributos de archivo… Desactive los permisos de Escribir y Ejecutar incluyendo todos los subdirectorios. Pulse el botón Aceptar. (recuerde la configuración actual, mas adelante necesitara volver a restaurarlos) Ej: solo se encuentran activados todos los permisos de Leer.
Recuerde dar permisos de escritura al directorio files.

Error 3: Cron maintenance tasks Never run
Cron has not run. For more information, see the online handbook entry for configuring cron jobs. You can run cron manually.
Posible solución: Pulse el enlace run cron manually (ejecutar cron manualmente). Se mostrara el mensaje Cron ran successfully (Cron ejecutado correctamente).

Error 4: Drupal core update status No update data available
Información No disponible acerca de las posibles nuevas versiones para los módulos y temas actualmente instalados. Para comprobar actualizaciones, puede necesitar ejecutar cron o puede comprobarlo manualmente.
Nota: La comprobación para las actualizaciones disponibles puede tardar bastante tiempo, sea paciente.
Posible solución: Ejecute cron manualmente, a continuación vuelva a este error y haga clic sobre el enlace check manually.
Nota: En modo local posiblemente aparezca el mensaje: Unable to fetch any information about available new releases and updates. Esto es debido a que no se encuentra conectado a internet.
Configuración de primeros usuarios.

18- Como su sitio esta en desarrollo, es conveniente que no permita (de momento) el registro de nuevos usuarios.
Para ello seleccione Administer > User management > User settings, en el apartado Opciones de registro para usuarios en Registros públicos: seleccione la primera opción: Sólo los administradores pueden crear cuentas para usuarios nuevos.
Pulse el botón Guardar configuración para guardar los cambios.

Listo... su sitio debería funcionar correctamente al cerrar e iniciar sesión.
Crear primera pagina de contenido en Drupal

(ejemplo)
Seleccione Create content > Historia
En el cuadro de texto Titulo escriba: Inicio
Seleccione el enlace Opciones del menú
En el cuadro de texto Título del enlace del menú escriba: Inicio
En el menú desplegable Elemento padre seleccione la opción: Navegación
En el cuadro de texto Cuerpo escriba el contenido deseado ej: Sitio en desarrollo, pronto estaremos con ustedes.
Pulse el botón Guardar.
Definir una pagina de inicio en Drupal

(ejemplo)
Primero tiene que saber cual es el node de la página para ello haga clic sobre el nombre de la página (Inicio). En la barra URL de su explorador web se mostrara la dirección de la página ej: http://www.proveedor.com/nombredesitio/nombrededirectorio/?q=node/1 siendo la última expresión el node/1

Seleccione Administer > Site configuration > Información del sitio
En el cuadro de texto de Página predefinida de inicio: escriba el (node / numero) asignado a la dirección de su pagina en el sitio ejemplo de la pagina de inicio: node/1
Pulse el botón Guardar configuración.

Videos de Drupal:
instalacion-y-uso-de-cron
02.-curso-de-drupal.-la-interface-de-administracion
03.-curso-de-drupal.-personalizacion-sitio
04.-curso-de-drupal.-administracion-usuarios
05.-curso-de-drupal.-creacion-de-formularios
06.-curso-de-drupal.-creacion-de-contenidos
07.-curso-de-drupal.-entender-los-nodos
08.-curso-de-drupal.-crear-contenidos-y-tipos-de-contenidos
09.-curso-de-drupal.-blogs-foros-y-encuestas
10.-curso-de-drupal.-taxonomia.-clasificar-contenidos
11.-curso-de-drupal.-agregar-feeds
12.-curso-de-drupal.-formatos-de-entrada-y-comentarios
13.-curso-de-drupal.-personalizacion-de-temas
14.-curso-de-drupal.-instalar-temas
15.-curso-de-drupal.-uso-de-modulos
16.-curso-de-drupal.-uso-de-menus
17.-curso-de-drupal.-crear-libros
18.-curso-de-drupal.-usar-php
19.-curso-drupal.-primer-proyecto.-primera-parte
20.-curso-drupal.-primer-proyecto.-segunda-parte
21.-curso-drupal-practico.-sistema-alquiler-pisos.-primera-parte
Video de Drupal en Vimeo

¿Cómo ejecutar aplicaciones servlet resumen de una línea de comandos

Tomado de:
http://translate.google.com.ec/translate?hl=es&langpair=en|es&u=http://www.mrc-productivity.com/support/manual/servletmanual/Advanced_Config/How_to_execute_servlet_summary_from_command_line.htm


¿Cómo ejecutar aplicaciones servlet resumen de una línea de comandos

For m-Power and BED running on the remote server: Para m-Power y CAMA ejecuta en el servidor remoto:

This example assumes that the m-Power and BED is located on C: drive of the server: Este ejemplo asume que el M-Power y Bed está ubicado en la unidad C: del servidor:

1. 1. Create a servlet summary using the 'Summaries' tab, compile the application. Crear un resumen de servlets usando la pestaña 'Síntesis', compilar la aplicación. Let's say the servlet summary application # is 740, and it has one run-time selection criteria ('Record Selection Criteria' link, STATE RG ? - prompts for a range of state codes, IL WI passed to the summary program). Digamos que la aplicación se resumen servlet # 740, y tiene un tiempo de ejecución de los criterios de selección (enlace "Registro de los criterios de selección, ESTADO RG? - Le pide a una serie de códigos de estado, IL WI pasado al programa de síntesis).

2. 2. There are three ways of executing the servlet summary to write the records to the file: Hay tres formas de ejecutar el resumen de servlet para escribir los registros en el archivo:

a. a. Use the command line (DOS prompt) and run: Utilice la línea de comandos (DOS) y ejecute:

cd C:\m-power\mrcjava\WEB-INF (press 'Enter', then type next line) cd C: \ M-Power \ mrcjava \ WEB-INF (presione 'Enter', luego la línea siguiente tipo)
java -classpath lib/mrcjs11.jar;classes/.;C:/m-power/tomcat/common/lib/servlet-api.jar;C:/m- power/tomcat/shared/lib/jt400.jar MRCWORKLIB.S00740s "" "" "IL WY" java-classpath lib/mrcjs11.jar; clases /., C: / m-power/tomcat/common/lib/servlet-api.jar C: / m-MRCWORKLIB power/tomcat/shared/lib/jt400.jar. S00740s "" "" "IL WY"

b. b. Create an executable file by placing the two lines in any text editor and saving the file with .bat extension on Crear un archivo ejecutable mediante la colocación de las dos líneas en cualquier editor de texto y guardar el archivo con extensión. Murciélago en

the server where m-Power resides. el servidor donde reside M-Power. Double click on the .bat file to execute. Haga doble clic en el bat. Archivo a ejecutar.

The lines are: Las líneas son:

cd C:\m-power\mrcjava\WEB-INF cd C: \ M-Power \ mrcjava \ WEB-INF
java -classpath lib/mrcjs11.jar;classes/.;C:/m-power/tomcat/common/lib/servlet-api.jar;C:/m-power/tomcat/shared/lib/jt400.jar MRCWORKLIB.S00740s "" "" "IL WY" java-classpath lib/mrcjs11.jar; clases /., C: / m-power/tomcat/common/lib/servlet-api.jar; C: / MRCWORKLIB m-power/tomcat/shared/lib/jt400.jar. S00740s "" "" "IL WY"

c. c. Use the two lines in the Windows server scheduler to execute the summary file: Utilice las dos líneas en el programador de servidor de Windows para ejecutar el archivo de resumen:

The lines are: Las líneas son:

cd C:\m-power\mrcjava\WEB-INF cd C: \ M-Power \ mrcjava \ WEB-INF
java -classpath lib/mrcjs11.jar;classes/.;C:/m-power/tomcat/common/lib/servlet-api.jar;C:/m-power/tomcat/shared/lib/jt400.jar MRCWORKLIB.S00740s "" "" "IL WY" java-classpath lib/mrcjs11.jar; clases /., C: / m-power/tomcat/common/lib/servlet-api.jar; C: / MRCWORKLIB m-power/tomcat/shared/lib/jt400.jar. S00740s "" "" "IL WY"

The example assumes: El ejemplo supone que:

m-Power, BED loaded on the C: drive of the server. M-Power, BED cargados en la unidad C: del servidor.

MRCWORKLIB - data dictionary in which the summary application that created the file exists MRCWORKLIB - diccionario de datos en la que el resumen de la solicitud que creó el archivo existe

S00740s - summary program that created the summary file S00740s - Resumen del programa que creó el archivo de resumen

"" "" - two blank parameters needed to execute the summary "" "" - En blanco dos parámetros necesarios para ejecutar el resumen

"IL KY" - run-time selection criteria for the state range (STATE RG ?). "IL KY" - tiempo de ejecución de los criterios de selección para la gama del Estado (Estado RG?).

NOTE: If the summary application requires more then one run time selection criteria indicated by ? NOTA: Si el resumen de la solicitud requiere más de una vez los criterios de selección enunciados por correr? in the 'Record Selection Criteria' option, those need to be listed in "". en la opción "Registro de los criterios de selección, los hay que figuran en el" ". The first two "" "" (blank spaces enclosed in double quotes) are default values that must be included in the string right after the summary application number. There is one blank space between each parameter passed to the summary application. Los dos primeros "" "" (espacios en blanco entre comillas) son los valores por defecto que debe incluirse en el derecho después de la cadena de número de solicitud de resumen. Hay un espacio en blanco entre cada parámetro que se pasa a la aplicación de resumen.

For mrc-Productivity Series users on 5250: MRC para los usuarios de la productividad de la serie en 5250:

1. 1. Create a servlet summary using the 'Summaries' option, compile the application. Crear un resumen de servlets usando la opción 'Síntesis', compilar la aplicación. Let's say the servlet summary application # is 740, and it has one run-time selection criteria ('Record Selection Criteria' link, STATE RG ? - prompts for a range of state codes, IL WI passed to the summary program). Digamos que la aplicación se resumen servlet # 740, y tiene un tiempo de ejecución de los criterios de selección (enlace "Registro de los criterios de selección, ESTADO RG? - Le pide a una serie de códigos de estado, IL WI pasado al programa de síntesis).

2. 2. There is a way of executing the servlet summary to write the records to the file: Hay una manera de ejecutar el resumen de servlet para escribir los registros en el archivo:

- Use the command line and run: - Utilice la línea de comandos y ejecutar:

QSH to start QSH session QSH para iniciar la sesión QSH

cd /mrcjava/WEB-INF (press 'Enter' key) cd / mrcjava / WEB-INF (presione 'Enter')

java -classpath classes/.:lib/mrcjs11.jar:/mrcjava/mrcclasses/jsdk.jar:lib/jt400.jar MRCWORKLIB.S00740s "" "" "IL WI" (press 'Enter' key) clases de java-classpath /.: lib/mrcjs11.jar: / mrcjava / mrcclasses / jsdk.jar: MRCWORKLIB.S00740s lib/jt400.jar "" "" "IL WI" (presione 'Enter')

The example assumes: El ejemplo supone que:

MRCWORKLIB - data dictionary in which the summary application that created the file exists MRCWORKLIB - diccionario de datos en la que el resumen de la solicitud que creó el archivo existe

S00740s - summary program that created the summary file S00740s - Resumen del programa que creó el archivo de resumen

"" "" - two blank parameters needed to execute the summary (with one blank space between them) "" "" - En blanco dos parámetros necesarios para ejecutar el resumen (con un espacio en blanco entre ellas)

"IL KY" - run-time selection criteria for the state range (STATE RG ?). "IL KY" - tiempo de ejecución de los criterios de selección para la gama del Estado (Estado RG?).

NOTE: If the summary application requires more then one run time selection criteria indicated by ? NOTA: Si el resumen de la solicitud requiere más de una vez los criterios de selección enunciados por correr? in the 'Record Selection Criteria' option, those need to be listed in "". en la opción "Registro de los criterios de selección, los hay que figuran en el" ". The first two "" "" (blank spaces) are default values that must be included in the string right after the summary application number. There is one blank space between each parameter passed to the summary application. Los dos primeros "" "" (espacios en blanco) son los valores por defecto que debe incluirse en el derecho después de la cadena de número de solicitud de resumen. Hay un espacio en blanco entre cada parámetro que se pasa a la aplicación de resumen.

Ejecución de un Servlet en Tomcat
Download and install Tomcat Descargar e instalar Tomcat

1. Download jakarta-tomcat-3.2.4.zip from http://jakarta.apache.org/builds/jakarta-tomcat/release/v3.2.4/bin/ . I downloaded it to the top level of the C: drive. Yakarta Descargar-tomcat-3.2.4.zip de http://jakarta.apache.org/builds/jakarta-tomcat/release/v3.2.4/bin/. He descargado a un nivel superior de la C: la unidad. (The actual location doesn't matter.) (La ubicación real no importa.)
2. Unzip it. Descomprimirlo. It creates a subdirectory called jakarta-tomcat-3.2.4 . Se crea un subdirectorio llamado jakarta-tomcat-3.2.4

Set the JAVA_HOME environment variable Establezca el entorno JAVA_HOME variable
Set the environment variable JAVA_HOME to C:\JBuilder5\jdk1.3.1 , or wherever jdk1.3.1 is located on your machine. Establecer el entorno JAVA_HOME variable a C:\JBuilder5\jdk1.3.1 o donde jdk1.3.1 se encuentra en su máquina. You can set environment variables either in Settings->ControlPanel->System->Environment or in a Command Prompt window. When a environment variable is set in a Command Prompt window, that setting applies only to that window. Puede establecer las variables de entorno, ya sea en Settings->ControlPanel->System->Environment o en una ventana de Símbolo del sistema. Cuando una variable de entorno se establece en una ventana de Símbolo del sistema, que se ajuste sólo se aplica a la ventana.

When setting environment variables, do not use quotatation marks and do not put spaces around the equal sign when using the set command in a Command Prompt window. Al establecer las variables de entorno, no use las marcas de quotatation y no poner espacios alrededor del signo igual cuando se utiliza el comando set en una ventana del símbolo del sistema. For example, to set JAVA_HOME , write Por ejemplo, para establecer JAVA_HOME escribir

set JAVA_HOME=C:\JBuilder5\jdk1.3.1

Start Tomcat and access a file Inicio de Tomcat y acceder a un archivo
Tomcat is now ready to run. Tomcat está listo para funcionar. To run it and have it serve a file, do the following. Para ejecutar el programa y tienen que servir a un archivo, haga lo siguiente.

1. Start a Command Prompt window. Inicie una ventana de Símbolo del sistema.
2. Change directory to the bin subdirectory of the Tomcat directory and run the startup command. In my case, Sitúese en el subdirectorio bin del directorio de Tomcat y ejecutar el comando startup En mi caso,

cd C:\jakarta-tomcat-3.2.4\bin
startup

3. A new Command Prompt window will be opened with Tomcat running. Note that when Tomcat starts, it sets two additional environment variables. Una nueva ventana del símbolo del sistema se abrirá con Tomcat corriendo. Tenga en cuenta que cuando Tomcat se inicia, dos conjuntos de variables de entorno adicionales.
1. It sets TOMCAT_HOME to the Tomcat home directory, in my case to C:\jakarta-tomcat-3.2.4 . Establece TOMCAT_HOME en el directorio principal de Tomcat, en mi caso a C:\jakarta-tomcat-3.2.4 (Note that in Windows, %TOMCAT_HOME% refers to the contents of the TOMCAT_HOME environment variable.) (Tenga en cuenta que en %TOMCAT_HOME% se refiere al contenido de la variable de entorno TOMCAT_HOME
2. It sets CLASSPATH to include %TOMCAT_HOME%\lib\servlet.jar . Establece CLASSPATH para %TOMCAT_HOME%\lib\servlet.jar

To ask Tomcat to serve a file, enter http://localhost:8080/examples/servlets/index.html into a browser. This (pure html) page lists some example servlets that come with Tomcat. Para pedir Tomcat para servir a un archivo, introduzca http://localhost:8080/examples/servlets/index.html en un navegador. Esto (html puro) página muestra algunos servlets ejemplo que vienen con Tomcat. There is nothing special about this file itself. No hay nada especial acerca de este archivo en sí.
Two things worth noting about this URL. Cabe señalar dos cosas acerca de esta URL.

1. The host is localhost:8080 . El anfitrión es localhost:8080 (By default Tomcat listens on port 8080.) (Por defecto Tomcat escucha en el puerto 8080.)
2. The address (ie, path) is examples/servlets/index.html . When Tomcat sees a URL, it consults its server.xml file (which is in %TOMCAT_HOME%/conf ) to see if the path in the URL has been defined as a web application. La dirección (es decir, la ruta) es examples/servlets/index.html Tomcat Cuando ve una dirección URL, consulta su archivo server.xml (que está %TOMCAT_HOME%/conf para ver si la ruta en la dirección URL se ha definido como una aplicación web. In this case it has been. En este caso ha sido. The file %TOMCAT_HOME%/conf/server.xml contains the following near the bottom. %TOMCAT_HOME%/conf/server.xml archivo %TOMCAT_HOME%/conf/server.xml contiene lo siguiente cerca de la parte inferior.



This is a mapping from a URL address path to an internal location. Esta es una asignación de una ruta de dirección URL a un lugar interior.
1. The path attribute defines /examples as a URL address which should be mapped to a special place on the disk and which may be associated with a Servlet. El atributo de path se define /examples como una dirección URL que debe ser asignado a un lugar especial en el disco y que pueden estar asociados con un servlet.
2. The docBase attribute defines webapps/examples as the place on the disk to associate with the path /examples . El atributo docBase define webapps/examples como el lugar en el disco de asociarse con la ruta /examples
3. In other words, the above tag tells Tomcat to map En otras palabras, la etiqueta encima dice que Tomcat mapa

http://localhost:8080/examples/

to para

%TOMCAT_HOME%/webapps/examples/

So when the user asks for Así que cuando el usuario pide

http://localhost:8080/examples/servlets/index.html

Tomcat actually access the file Tomcat realmente tener acceso al archivo

%TOMCAT_HOME%/webapps/examples/servets/index.html

4. There is such a file, which comes with the Tomcat download. When Tomcat is unzipped, it creates an examples directory as a subdirectory of %TOMCAT_HOME%/webapps . No es un archivo, que viene con la descarga de Tomcat. Cuando se abrió la cremallera de Tomcat, crea un directorio de examples como un subdirectorio %TOMCAT_HOME%/webapps That examples directory has a servlets subdirectly, which has an index.html file in it. Ese directorio de examples tiene un servlets subdirectly, que tiene un archivo index.html en el mismo.

Run a Servlet Ejecutar un servlet

1. One of the links in the file http://localhost:8080/examples/servlets/index.html is to ../servlet/HelloWorldExample . Uno de los eslabones de la http://localhost:8080/examples/servlets/index.html archivo es ../servlet/HelloWorldExample On first glance, this looks like it should be referring to a file at %TOMCAT_HOME%/webapps/examples/servlet/HelloWorldExample . A primera vista, esto parece que se refiere a un archivo %TOMCAT_HOME%/webapps/examples/servlet/HelloWorldExample But there is no such file. Pero no hay tal archivo. In fact, there is no such directory as %TOMCAT_HOME%/webapps/examples/servlet/ . De hecho, no hay directorio, %TOMCAT_HOME%/webapps/examples/servlet/
2. Instead, by convention, a reference to what appears to be a servlet directory at the top level of a mapped webapp address means: execute the indicated servlet. En su lugar, por convenio, una referencia a lo que parece ser un directorio de servlet en el nivel superior de una dirección asignada webapp significa: ejecutar el servlet indicado. In this case, execute the servlet called HelloWorldExample . En este caso, ejecutar el servlet llamado HelloWorldExample
3. Servlets are simply .class files, ie, compiled .java files. Servlets son .class Archivos .class es decir, .java Archivos .java
4. Servlet files are stored in the WEB-INF/classes subdirectory of the main web application directory. Servlet archivos se almacenan en el subdirectorio WEB-INF/classes de los principales del directorio de aplicaciones web. In this case the .class files for the examples web app is stored in %TOMCAT_HOME%/webapps/examples/WEB-INF/classes . En este caso los archivos de .class Para la aplicación examples la Web se almacena %TOMCAT_HOME%/webapps/examples/WEB-INF/classes
5. So when the user requests Así que cuando el usuario solicita

http://localhost:8080/examples/servlet/HelloWorldExample http://localhost:8080/examples/servlet/HelloWorldExample

Tomcat runs Tomcat se ejecuta

%TOMCAT_HOME%/webapps/examples/WEB-INF/classes/HelloWorldExample.class

Create and run your own Servlet Crear y ejecutar su propio Servlet
# Download HelloWorld.java from http://archive.corewebprogramming.com/Chapter19.html to anywhere. Descargar HelloWorld.java de http://archive.corewebprogramming.com/Chapter19.html a cualquier parte.
# Change directory to the location where you stored HelloWorld.java and compile it with javac HelloWorld.java Cambie el directorio a la ubicación donde se almacena HelloWorld.java y compilarlo con javac HelloWorld.java
# Move the resulting .class file to %TOMCAT_HOME%/webapps/examples/WEB-INF/classes . Mueva el .class de archivo %TOMCAT_HOME%/webapps/examples/WEB-INF/classes
# (Instead of using the %TOMCAT_HOME%/webapps/examples/WEB-INF/classes directory, we could have created an entirely new web app. That would have required adding another Context entry to the server.xml file. Had we done that, we would have had to restart Tomcat. To restart Tomcat, call shutdown and then startup again in the Command Prompt window in which we had originally started Tomcat.) (En lugar de utilizar %TOMCAT_HOME%/webapps/examples/WEB-INF/classes directorio, que han creado una aplicación web completamente nueva. Esto habría exigido agregar otra entrada Context a la de archivo server.xml Si hubiéramos hecho eso, que hubiéramos tenido que reiniciar Tomcat. Para reiniciar Tomcat, llame al shutdown y startup de nuevo en la ventana del símbolo del sistema en el que habíamos empezado Tomcat.)
# In a brower, access, http://localhost:8080/examples/servlet/HelloWorld . Your servlet will run. En un Brower, acceso http://localhost:8080/examples/servlet/HelloWorld. El servlet se ejecutará.

Uso de Quartz para tareas programadas en Tomcat

Tomado de:
http://www.javisjava.com/blog/


Quartz
19 Comments Published Junio 29th, 2008 in General

Quartz es un programador de tareas en Java. Para empezar, hay que decir que J2SE ya viene de serie con soporte para la programación de tareas, gracias a las clases Timer y TimerTask, que son capaces de lanzar un hilo por cada tarea que se ejecuta.
Sin embargo, Quartz va más allá, pues aporta un framework mucho más completo, y con características interesantes, como:

* Configuración declarativa (ficheros XML o properties), además de programática.
* Multitud de opciones de programación (por ejemplo, sintaxis tipo cron).
* Mantenimiento de estado de las tareas.
* Potente gestión de errores o tareas incompletas recuperables.
* Disponibilidad de Listeners no intrusivos sobre las tareas, los disparadores o sobre el propio programador.
* Integración con aplicaciones web vía Servlet o ContextListener.
* Integración con Spring.
* Soporte a entorno distribuido (cluster).

Es muy común la necesidad de dar de alta procesos periódicos asociados a una aplicación web. Quartz es especialmente útil precisamente porque elimina la obligación de tener crones de Linux o tareas programadas de Windows, de forma que toda nuestra aplicación, con la funcionalidad completa, reside en el WAR.
Estos son los pasos para dar de alta una tarea en una aplicación web de la forma más sencilla.

1. Se descarga Quartz, y se introducen en el WEB-INF/lib de la aplicación el JAR del propio Quartz y todos de los que depende (están incluidos en la distribución).
2. En el fichero web.xml se da de alta un listener, QuartzInitializerListener. Se trata de un ContextListener, que ejecuta automáticamente un método en el arranque de la aplicación (arranca el programador de tareas) y otro en la parada (obviamente, para el programador).


<web-app ... >
    <display-name>QuartzExample</display-name>
    <listener>
        <listener-class>org.quartz.ee.servlet.QuartzInitializerListener</listener-class>
    </listener>
</web-app>




3. Una vez arrancado, el programador buscará su configuración. Por defecto, deberá estar en un fichero de nombre quartz.properties en el raíz del classpath (WEB-INF/classes). El contenido de este fichero para una tarea simple, sin gestión del estado, soporte para cluster, etc, sería:

# Programador #
org.quartz.scheduler.instanceName = DefaultQuartzScheduler
org.quartz.scheduler.rmi.export = false
org.quartz.scheduler.rmi.proxy = false
org.quartz.scheduler.wrapJobExecutionInUserTransaction = false
# Hilos #
org.quartz.threadPool.class = org.quartz.simpl.SimpleThreadPool
org.quartz.threadPool.threadCount = 10
org.quartz.threadPool.threadPriority = 5
org.quartz.threadPool.threadsInheritContextClassLoaderOfInitializingThread = true
# Almacenamiento #
org.quartz.jobStore.misfireThreshold = 60000
org.quartz.jobStore.class = org.quartz.simpl.RAMJobStore
# Plugins #
org.quartz.plugin.jobInitializer.class = org.quartz.plugins.xml.JobInitializationPlugin
org.quartz.plugin.jobInitializer.overWriteExistingJobs = true
org.quartz.plugin.jobInitializer.failOnFileNotFound = true
org.quartz.plugin.jobInitializer.validating=false


4. Las últimas líneas del quartz.properties están configurando un plugin capaz de incorporar las tareas y disparadores de un fichero XML. De nuevo, usaremos convención sobre configuración, de modo que llamaremos a ese fichero quartz_jobs.xml, y también lo situaremos en WEB-INF/classes, con el siguiente contenido:
<quartz ... >
    <job>
        <job-detail>
            <name>QuartzExampleJob</name>
            <group>ExampleGroup</group>
            <description>ExampleJob</description>
            <job-class>com.javisjava.quartz.jobs.QuartzExampleJob</job-class>
            <job-data-map allows-transient-data="false">
                <entry>
                    <key>nombre</key>
                    <value>Javier</value>
                </entry>
            </job-data-map>
        </job-detail>
        <trigger>
            <cron>
                <name>QuartzExampleTrigger</name>
                <group>ExampleTriggerGroup</group>
                <job-name>QuartzExampleJob</job-name>
                <job-group>ExampleGroup</job-group>
                <!-- Se dispara cada 10 segundos -->
                <cron-expression>0/10 * * * * ?</cron-expression>
            </cron>
        </trigger>
    </job>
</quartz>


Este XML indica que debe ejecutarse la tarea definida en la clase QuartzExampleJob, con un parámetro de configuración de clave nombre y valor Javier. La tarea se ejecutará según el calendario definido en el disparador de tipo cron QuartzExampleTrigger (cada 10 segundos).
5. Las clases que contienen las tareas deben implementar la interfaz org.quartz.Job, que sólo contiene el método execute. Éste es nuestro ejemplo, que lanza un mensaje en la consola, apoyado en el parámetro que se le pasa en el XML (pueden ser múltiples parámetros, mientras su clave sea distinta).

package com.javisjava.quartz.jobs;

import org.quartz.Job;
import org.quartz.JobExecutionContext;
import org.quartz.JobExecutionException;

public class QuartzExampleJob implements Job {

    public void execute(JobExecutionContext context) throws JobExecutionException {
        System.out.println("Hola "
            + context.getJobDetail().getJobDataMap().getString("nombre"));
    }

}
6. Al arrancar la aplicación web, aparecerá “Hola Javier” en la consola del contenedor cada 10 segundos.
Os dejo un WAR totalmente funcional que incluye el código para poder modificar la tarea fácilmente.

Como os he dicho, Quartz se puede integrar también en la configuración de Spring, que es el modo recomendado si estáis usando este framework. Hay una sección de la referencia de Spring que cubre cómo hacerlo.

Para profundizar en el manejo de Quartz, acudid a la documentación, o al libro monográfico sobre este framework que ha escrito Chuck Cavaness.

*Edición: tras el comentario de Paul donde pregunta cómo actualizar el trigger una vez iniciado el proceso, he subido proyecto Eclipse muy sencillo donde se muestra la forma de hacerlo.

Vídeo: Crear icono favicon.ico para una web con Gimp

Tomado de:
http://www.desarrolloweb.com/articulos/video-crear-icono-favicon-gimp.html

Vídeo tutorial de la creación de un icono para una web, que se mostrará en la barra de direcciones y el menú favoritos, conocido por favicon.ico, utilizando Gimp para crear el icono.
Por Miguel Angel Alvarez
Publicado: 26/2/10
Atención: Contenido exclusivo de DesarrolloWeb.com. No reproducir. Copyright.
Tanto en las páginas web personales como en las más profesionales podemos encontrar un icono en la barra de direcciones con el logotipo de la web, o cualquier otra imagen que la simbolice. Este icono lo puede definir el desarrollador de una manera sencilla, como veremos en el presente vídeo.

Este icono, muchas veces conocido simplemente como "favicon", lo podremos ver en varios sitios, como puede ser la barra de direcciones, a la izquierda de la URL, en el menú de favoritos (cuando el visitante marca la web como favorita) o en las pestañas. En ocasiones también podemos referirnos a él como Icono de Favoritos y es que favicon sería justamente su abreviación.

Hace años en DesarrolloWeb.com publicamos un artículo sobre este tema, cuando el icono de favoritos era una novedad. Sin embargo hace un tiempo la manera de incluir este icono se ha simplificado bastante, por lo que convenía actualizar nuestros tutoriales. Además, para agregar un valor añadido a este tutorial hemos pensado que sería interesante mostrar también cómo podríamos hacer nosotros mismos un icono con un programa gratuito. El texto del artículo antiguo se puede encontrar en Icono en Favoritos que además está complementado por los comentarios de decenas de personas. De hecho, hemos seguido la sugerencia del usuario "Spiderdraw" que comenta que ese icono se puede hacer con Gimp.

Como muchos sabrán, Gimp es un programa de edición gráfica de código libre y multiplataforma, que sería la alternativa gratuita más profesional al archiconocido Photoshop. Gimp tiene una opción para guardar como "ico", es decir, archivos con extensión .ico, que son los que necesitamos para definir el icono favicon.

En este vídeo mostraremos cómo se crea el icono en favoritos para una web, a partir del retoque de la imagen del logotipo de la web. Copiaremos la imagen que se utiliza como logo y la formatearemos para que tenga las dimensiones de 16x16 píxeles, que son las que necesitamos para el icono. Luego guardaremos ese archivo gráfico como "favicon.ico", para que los navegadores lo puedan reconocer.

El siguiente paso será subir el icono por FTP y colocarlo en la raíz del dominio, es decir, en el directorio raíz de publicación de nuestro sitio web. Como decimos, los navegadores buscarán automáticamente, sin que tengamos que indicarles nada, por el archivo "favicon.ico" de la raíz del dominio y lo mostrarán en la barra de direcciones, sin que tengamos que realizar ningún otro paso.

Al acabar el vídeo mostraremos simplemente cómo distintos navegadores muestran nuestro icono favicon. Lo mejor es que vosotros mismos sigáis las explicaciones y modos de trabajo que se ofrecen en el vídeo, que servirán para aprender a colocar nuestro icono favicon.ico y para aprender un poquito sobre el modo de trabajo con el editor gráfico Gimp.

Impresión en el cliente en WEB

Tomado de:
http://wiki.gxtechnical.com/commwiki/servlet/hwiki?Impresi%C3%B3n+en+WEB,

Impresión en el cliente en WEB

En interfaz WEB, hasta ahora había constituido un desafío el hecho de imprimir reportes en la impresora del cliente, sin intervención del usuario. Ahora es posible hacerlo de una forma más inmediata e intuitiva.

Las posibilidades de impresión dentro de lo que es modo gráfico, son en general, formato PDF o reportes gráficos usando la herramienta ReportViewer. El uso de cualquiera de estas variantes depende de la plataforma y la interfaz usada. En interfaz GUI Windows, es válido el uso del ReportViewer. En interfaz GUI linux no lo es, debido a que la implementación del Report.Viewer está basada en dlls para su funcionamiento. En interfaz WEB tampoco es válido el uso de dicha herramienta, porque no es posible ejecutar el ReportViewer dentro del browser (es una aplicación GUI).

En plataforma WEB, los reportes mayoritariamente usados, son los reportes gráficos en formato PDF, que se despliegan en el browser del cliente, dentro del cual ejecuta el Acrobat Reader.

Si bien el reporte PDF se visualiza en el browser, hasta la versión 9.0 no había una manera inmediata de enviar ese reporte a imprimir, en la impresora del cliente (sin intervención del usuario). Esto es porque en dicho ambiente el cliente es un browser (Internet Explorer, FireFox, etc), y la dificultad está vinculada al hecho de acceder al driver de impresión dentro del PC cliente donde ejecuta dicho browser.

Sin embargo, a partir del upgrade 1 de los generadores Java y NET existe la posibilidad de que el usuario, presionando un botón pueda mandar a imprimir un reporte PDF a su impresora, sin tener que pasar por el diálogo de impresión.

A nivel del desarrollador GeneXus, no hay programación adicional, cualquier reporte GeneXus que cumpla con las condiciones de ser un reporte PDF, y que además posea salida a impresora (lo cual se hace en GeneXus a través de una propiedad llamada "Report Output"), se imprimirá en la impresora conectada al PC donde ejecuta el navegador web.
La aparición del diálogo de impresión es configurable, al igual que en cualquier modelo GeneXus que trabaje con reportes. Igualmente, si la aplicación corre en una Intranet, donde las impresoras son conocidas, se puede manejar desde el servidor la selección de la impresora.
Se tendrá todo el dinamismo que ya existe en el manejo de reportes, logrando que los mismos accedan a los drivers de impresión del PC cliente, sin intervención del usuario final (diálogo de impresión), si asi se desea.
A continuación, siguen algunos ejemplos y un xpz para ejecutar.

Sample I :Como mandar a imprimir el PDF directo a la impresora del PC

Para mandar a imprimir el reporte en web desde la máquina que ejecuta el browser (cliente), el reporte debe cumplir con lo siguiente:

Debe ser main
La propiedad Call protocol debe ser http
La propiedad "Report Output" debe ser "Only to Printer"
Se debe configurar la regla output_file("x.pdf","PDF")
Solo con esos pasos se logra que el reporte PDF se visualice en pantalla, a la vez que se envía a imprimir a la impresora del PC cliente, indicada en la regla printer (1).

Descargar el ejemplo de aqui:
Basic Sample Silent Printing

Sample II : Evitar que el reporte se visualice en pantalla
Si se desea evitar que se despliegue el reporte en pantalla, antes de enviarlo a la impresora, se puede direccionar el reporte a una Embedded Page de tamaño 1 x 1.
Descargar el ejemplo de aquí:

Silent Print Sample Without showing page

Sample III: Evitar que el usuario interrumpa la impresión
Para evitar que el usuario presione un botón del form durante la impresión del reporte (lo cual la interrumpiría), es posible agregar javascripts para deshabilitar los controles (botones y links) hasta que la impresión finalice.
Se usa una cookie en la solución. El tema es que cuando se hace la invocación al reporte vuelve un response sin el archivo, por lo cual en ese momento no es adecuado habilitar los botones. Por eso, recien cuando vuelve el segundo response con el archivo, se habilitan los botones.
La implementación está hecha de tal manera de que antes de mandar la impresión se graba la cookie.
Luego, se setean intervalos de tiempo con un javascript, para que cada X tiempo se consulte esa cookie.
El reporte al finalizar graba la cookie, con lo cual, detectado esto, se habilitan los botones.

El hecho de deshabilitar el form en el POST se hará en forma automática en un próximo upgrade.

Bajar el ejemplo:

Silent Print Sample with Javascripts

ANEXO Donde mandar a imprimir?


Regla printer y gxprn.ini
En cualquiera de los casos, las configuraciones de impresión, como siempre, se toman del archivo gxprn.ini (1), y mediante la regla printer se especifica la entrada dentro de ese archivo que contiene la configuración que se desea tomar.
Cuando un reporte con regla printer se ejecute, irá a buscar al archivo una entrada con el mismo nombre que se le puso en la regla. De no existir ninguna entrada con ese nombre, o de no existir el archivo gxprn.ini, el reporte se tratará de imprimir a la impresora por default.
Por ejemplo si la regla es :
printer('Facturas');
Se buscará una entrada "Facturas" dentro del gxprn.ini.
En el caso del generador Java, el gxprn.ini se debe ubicar en el mismo lugar que el pdfreport.ini o sea en el WEB-INF de la webapp.
En el caso del generador NET se debe ubicar en el directorio virtual, o en el directorio virtual\bin.
Si no se encuentra el gxprn.ini toma correctamente la impresora default.

Programa GXsetfrm

El archivo gxprn.ini se crea en el momento de la ejecución del programa "gxsetfrm". Este programa permite crear y modificar los diferentes "forms" (un "form" es una entrada en el gxprn.ini, con una determinada configuración).
El programa "gxsetfrm" es un programa win, se usa unicamente para configurar el gxprn.ini, y se lo debe llamar por ejemplo desde un evento de usuario de la siguiente forma: call("gxsetfrm").


Propied Show Printer Dialog on reports

Si no se encuentra el gxprn.ini, se considera la propiedad "Show Printer Dialog on reports", para mostrar o no el diálgo de impresión.
De lo contrario, si se encuentra el gxprn.ini, se toma en cuenta lo configurado alli. Para evitar que se muestre el diálogo de impresión, se especifica MODE = 0 en el gxprn.ini, en la entrada correspondiente de la impresora a usar.


Links relacionados

(1) Regla Printer:
http://www.gxtechnical.com/gxdlsp/pub/genexus_8.0_help_system/rules/printer_rule.htm

Generación de Reportes PDF:

http://www.gxtechnical.com/gxdlsp/pub/iehelp.htmGeneXus/DevEnv/Docum/ReleaseNotes/7.5/ReportesPDF.htm

Editores de HTML

Tomado de:

http://www.lawebera.es/manual-diseno-web/herramientas-para-disenadores-web-editores-html.php

Herramientas para diseñadores web: Editores HTML

Si bien hoy en día continúa la discusión acerca de la conveniencia o no de emplear editores WYSISYG o no, sin entrar en hacer argumentaciones sobre ello, pasaremos a describir una de las herramientas indispensables para todo diseñador web: los editores HTML.

Algunos diseñadores prefieren seguir escribiendo el código directamente sobre un editor de texto plano, al estilo del Bloc de Notas de Microsoft, otros prefieren los editores de texto especializados en lenguajes web y de programación, otros prefieren los editores de texto con ventana de vista previa, mientras que otros emplean la opción más avanzada, que son los editores WYSIWYG.

Los primeros generan el archivo HTML, las hojas de estilo y los scripts sobre una o varias hojas de texto plano y valoran los resultados directamente sobre el o los navegadores. Este método es el más primitivo, aunque no ha perdido vigencia. Durante el aprendizaje de los lenguajes de diseño web y de programación, todos los centros de enseñanza inician el estudio de HTML, XHTML y CSS con este rudimentario método. Y la razón es que es el mejor método para conocer a fondo los lenguajes de diseño y programación. La generación de código a partir de editores de texto plano implica necesariamente la comprensión plena del funcionamiento del sistema.

El segundo grupo de diseñadores emplean editores de texto, pero que tienen algunas funciones especializadas en los lenguajes de diseño web y programación, como autocompletado de etiquetas de cierre, coloreado de acuerdo a la sintaxis del lenguaje, posibilidad de seleccionar las etiquetas de una barra de herramientas y otras muy variadas. Por ejemplo, cuando se escribe una línea de código, ésta no adquiere los diferentes colores correspondientes a la sintaxis hasta que no está correctamente escrita. Para visualizar los resultados, emplean uno o más navegadores, a los que, tras cada cambio, se le hace click en el botón “refrescar” para ver los mismos.

El grupo de diseñadores que optan por la tercera opción, cuenta con una herramienta en el editor que hace las veces de navegador, por lo que pueden ir viendo los cambios que van efectuando a medida que los van haciendo.

Los editores WYSIWYG son algo bastante más complejo, y consiste en (tal como indica la sigla que les da nombre: What You See Is What You Get – Lo que ves es lo que obtienes) la creación de páginas web arrastrando y colocando, completado por elementos que permiten modificar los atributos de los elementos que se van colocando.


Editores de texto plano y navegador

Los diseñadores web que emplean esta opción desechan la ayuda que constituye el software especializado. No tiene muchas ventajas sobre el resto de los métodos, solo la certeza de que quienes lo hacen tienen un pleno dominio de los diferentes lenguajes. Como método de aprendizaje, seguramente sea el mejor, ya que el conocimiento del lenguaje deja de ser una opción para ser absolutamente obligatorio. Siempre, y no solo para quienes optan por este sistema de trabajo, es necesario contar con varios navegadores, siendo el mínimo recomendado de tres, ya que las diferencias en la interpretación del código por parte de los navegadores, obliga a visualizar las páginas en más de un navegador.
Editores de texto especializados en HTML y CSS

El desarrollo del diseño web y el creciente número de diseñadores ha planteado la posibilidad de crear herramientas especializadas en la escritura de códigos. La cantidad de editores de este tipo existentes es enorme, siendo en su mayoría gratuitos, aunque algunos son de pago o forman parte de paquetes de software para diseñadores web. Otra característica que los diferencia a unos de otros, es la especialización en los diferentes lenguajes. Algunos editores tienen soporte casi exclusivamente para HTML, aun cuando colorean varios lenguajes más, mientras que otros editores tienen herramientas especiales para diferentes tipos de lenguajes, incluyendo los lenguajes de programación.
Editores de texto especializados con ventana de vista previa

Comparten muchas de las características descriptas para el grupo de editores anteriores, con el elemento distintivo de poseer entre sus herramientas un visor en tiempo real (generalmente en la misma ventana que se escribe el código) que permite al diseñador web observar el resultado de lo que se encuentra escribiendo sin tener que ir a la ventana del navegador y refrescar la página.
Editores WYSIWIG

También cuenta entre sus herramientas la edición de los códigos sobre texto plano, aunque su mejor herramienta es la ventana donde el diseñador realiza las modificaciones arrastrando y soltando con el ratón, en un sistema similar al que se emplea en procesadores de texto como Microsoft Word o Writer.

Algunos de estos editores son de manejo tan sencillo, que para muchas de las tareas propias del diseño de páginas web no se requiere conocimiento de lenguaje HTML. Sin embargo, a la hora de darle atributos a los diferentes componentes de la página, el diseñador deberá contar con conocimientos básicos de HTML y CSS.


Elección del editor HTML

Cada diseñador debe desarrollar su método de trabajo, aquel con el que se sienta más cómodo. No existen recetas preestablecidas y hay tantas formas de trabajar como diseñadores. Lo mismo sucede con el software que se ha de seleccionar. En una primera instancia, el diseñador debe elegir el método que empleará y luego probar herramientas hasta encontrar una que lo satisfaga.

A continuación damos las descripciones de algunos de los programas más conocidos, pero solo son algunos de una muy amplia gama.
Algunos editores de texto especializados



Bluefish


Bluefish

* Desarrollado inicialmente para Linux, en la actualidad hay versiones para otros sistemas operativos como Solaris, MacOS-X y otros, aunque no existe una versión para Microsoft Windows.
* La última versión estable es la 1.07 de marzo de 2008.
* Soporta varios archivos abiertos a la vez
* Marcado de sintaxis personalizable para HTML, PHP, JSP, SQL, XML, CSS, Javascript, Python, Perl, Pascal y otros.
* Asistentes para creación de documentos.
* Asistentes para la creación de tablas y marcos.
* Soporta diferentes juegos de caracteres.
* Diálogos para la inserción de imágenes.
* Traducido a 22 idiomas, entre los que se encuentra el español.
* Gratuito.
* Licencia GPL.



Weaverslave

* Desarrollado para Windows, es compatible con todas las versiones de este sistema operativo desde Windows 95.
* Totalmente portable
* Última versión estable: 3.9.18 de noviembre de 2005.
* Puede trabajar con varios archivos a la vez.
* Marcado con colores de sintaxis para DHTML, CSS, JS, PHP (4 y 5), MySQL, PERL, C, C++ y otros.
* Ventana de colores.
* Inspector de etiquetas.
* Navegador de archivos e imágenes.
* Traducido a varios idiomas (incluidos) entre los que está el español.
* Gratuito.
* Software propietario.

Editores de texto con ventanas de vista previa



Aptana


Aptana Studio

* Windows, MacOS-X y Linux.
* Cliente FTP.
* Posibilidad de instalar un plug-in que permite la escritura en el lado del servidor.
* Panel de vista previa Firefox e Internet Explorer.
* Soporte principal para HTML, XHTML y CSS, aunque también cuenta con herramientas para Php, Python, Ruby, CSS, Ajax, HTML y Adobe AIR.
* Última versión: 2.0.2 de 2009.
* Marcado de sintaxis por colores.
* Una muy variada serie de herramientas y diálogos.
* Gratuito.
* GNU / GPL.



Arachnophilia

* Unix, Linux, MacOS-X y Windows
* Última versión: 5.4 (Octubre de 2009)
* Ventana de vista previa.
* HTML, CSS, JS, C++, CGI, PERL, Java y otros.
* Marcado de sintaxis en colores.
* Gratuito.
* Software propietario.



HTML-kit


HTML-Kit

* Este software solo es compatible con Microsoft Windows 95 en adelante.
* Ventana de vista previa múltiple.
* Validación de código.
* Cliente FTP.
* HTML, XHTML, XML, CSS, XSL, PHP, ASP, VB, C/C++, SQL, Java, Javascript, Delphi, Perl
* Sugerencias y sistema de corrección de errores.
* Gratis.
* Software propietario.

Editores WYSIWYG

Adobe Dreamweaver


Adobe Dreamweaver

* Versiones para Windows y MacOS-X.
* Última versión estable CS4 (10.0) de 2008.
* Se le considera el editor más potente, pero también el más pesado (354 MB antes de instalar) y el de mayores requerimientos de hardware.
* Requerimientos mínimos: procesador de más de 1 GHz, Windows XP o superior o Mac OS X v10.4.11–10.5.4, 512 MB de RAM, 1 GB de espacio libre en el disco, pantalla 1280 x 764 con tarjeta de 16 bits, DVD-ROM, banda ancha para servicios en línea.
* Ventana de visualización.
* Sugerencias de código.
* Herramientas avanzadas para imágenes de Photoshop (PSD).
* Utiliza CSS.
* Datos dinámicos (sencillos) sin empleo de XML ni bases de datos.
* Diseño sin escritura de código (aunque el usuario puede modificar el código manualmente).
* Alto costo (399 USD)
* Software propietario.

NVU
NVU

* Multiplataforma
* Última versión estable: 1.0 de junio de 2005. En la actualidad se ha abandonado su desarrollo.
* Cliente FTP.
* Edición de código fuente.
* Marcos, formularios, tablas, plantillas de diseño, hojas de estilo CSS, etc.
* Gratis.
* MPL / GPL / LGPL.

Amaya

* Multiplataforma
* Última versión: 11.1 de enero de 2009.
* Navegador.
* Genera páginas HTML 4.01, XHTML 1.0, XHTML Basic, XHTML 1.1, HTTP 1.1, MathML 2.0, muchas características CSS 2.
* Renderizado de imágenes.
* Herramientas para imágenes vectoriales (SVG).
* Edición WYSIWYG.
* Gratuito.
* Licencia W3C.

Problemas con STORED PROCEDURES en el ISeries

Hemos tenido problemas recurrentes cuando se utiliza llamados a STOREDPROCEDURES en el ISERIES, sobre todo el problema se agudiza cuando se llega al limite de almacenamiento, lo recomendable es modificar el porcetanje MINIMO DE ALMACENAMIENTO para que puedan ejecutarse los SP.

El momento en que se modfica automaticamente empiezan a funcionar los SP.

En este caso tenemos unos servicios web generados con Java de Sun en Tomcat .

GlassFish y Tomcat

Tomado de:
http://mx.sun.com/emrkt/innercircle/newsletter/0209/feature-itm.html?cid=e7959f

Si valora el rendimiento, la facilidad de uso y la agilidad de sus aplicaciones, considere detenidamente los detalles

El CEO siempre hace preguntas muy sencillas a la dirección de TI. ¿Por qué se quejan los clientes del nuevo sistema de pedidos en línea? ¿Por qué llevamos ocho meses intentando desplegar ese nuevo servicio Web? ¿Por qué falló esta mañana mi aplicación de informes financieros?

Lo que el CEO no suele preguntar es qué tecnología de servidor de aplicaciones utiliza la empresa. Pero en muchos casos, esa es la pregunta importante, porque hay una relación directa entre el servidor de aplicaciones utilizado por los equipos de desarrollo y el rendimiento y agilidad de las aplicaciones corporativas.

En concreto, la tecnología del contenedor Web utilizado en el servidor de aplicaciones puede ser un factor determinante para la calidad de las aplicaciones y la productividad de los desarrolladores. Con una tecnología de contenedor Web adecuada, los equipos de desarrollo abarcan más trabajo y las aplicaciones se desarrollan en menos tiempo y funcionan mejor. Una elección equivocada puede dar lugar a dolores de cabeza en el presente y en el futuro.

Si su negocio son las aplicaciones, merece la pena examinar detenidamente las entrañas del servidor de aplicaciones y la tecnología del contenedor Web y analizar su impacto en los equipos de desarrollo. En este artículo se comparan dos de las opciones de código abierto más populares: GlassFish y Tomcat.

Dos opciones populares, muchas diferencias importantes
GlassFish es el servidor de aplicaciones de código abierto creado por la comunidad GlassFish, lanzado por Sun en 2005, y que ha demostrado gozar de gran popularidad entre los desarrolladores. Actualmente, existen dos versiones principales: GlassFish v2 y la reciente Glassfish v3 Prelude. Hasta la fecha, se han descargado cerca de 9,000000 de copias de GlassFish v2, con 300,000 productos registrados sólo en 2009. GlassFish v3 Prelude ofrece nuevas características y mejoras. Es una excelente plataforma para desplegar aplicaciones de Internet con Java y lenguajes dinámicos como jRuby.


Mientras que GlassFish es un conjunto de contenedores Java EE, uno de los cuales es un contenedor Web, Tomcat es sólo un contenedor Web. Esta diferencia fundamental se traduce en una serie de ventajas importantes para GlassFish.
El servidor de aplicaciones Tomcat fue promovido por Apache y un grupo que incluía a desarrolladores de Sun y JServ. El código inicial procedía de Sun. Tomcat fue fundamental para la adopción de Java en servidores, se ofrecía con una licencia de código abierto y contribuyó decisivamente a la implantación del software de código abierto en las grandes empresas.

En general, las aplicaciones que funcionan en Tomcat lo harán sin necesidad de cambios en GlassFish. Sin embargo, hay diferencias importantes que afectan al rendimiento, la escalabilidad y la facilidad de uso de las aplicaciones, así como a la productividad de los desarrolladores.

Para comprender estas diferencias, es importante examinar la tecnología del contenedor Web subyacente. El contenedor Web es la parte de un servidor de aplicaciones que se encarga de manejar los servlets, las páginas JavaServer Pages (JSP) y otros componentes del nivel Web.

Mientras que GlassFish es un conjunto de contenedores Java EE, uno de los cuales es un contenedor Web, Tomcat es sólo un contenedor Web. Esta diferencia fundamental se traduce en una serie de ventajas importantes para GlassFish:

Ruta de migración más sencilla. Con GlassFish v2 hay una forma clara y sencilla de aprovechar tecnologías tales como Enterprise Java Beans (EJBs), Java Persistence API (JPA) y Java Message Service (JMS), entre otras. Con Tomcat, estas tecnologías deben agregarse poco a poco, una a una. El desarrollador es responsable de implementar las capacidades y de asegurarse de que todo el conjunto funcione.
Preparado para entornos de clustering con failover. GlassFish v2 ofrece capacidad de clustering y sofisticadas funciones de alta velocidad para que las aplicaciones puedan cumplir los exigentes acuerdos de nivel de servicio (SLA) de tipo empresarial. GlassFish v3 Prelude admite clustering a través de un equilibrador de carga, aunque todavía no tiene un perfil de clustering.
Superioridad en la administración y la supervisión. GlassFish v2 y v3 Prelude permiten la administración centralizada a través de una consola de administración y de una interfaz de línea de comandos (CLI). GlassFish v2 ofrece supervisión Callflow, que permite a un desarrollador de aplicaciones o un administrador de servidores determinar a qué dedica la aplicación la mayor parte de su tiempo. Esta característica también estará disponible en GlassFish v3. Además, otros proveedores pueden ofrecer su software a través de GlassFish Update Center para facilitar la instalación en GlassFish. Con Tomcat, el software nuevo se configura de forma poco sistemática. Update Center también proporciona acceso en primicia a las nuevas versiones de tecnologías tales como EJB 3.1, que permite empaquetar EJB en un WAR en lugar de empaquetar la aplicación en un archivo EAR.
Compatibilidad con lenguajes de script. GlassFish admite, o lo hará en breve, Ruby/JRuby, Python/Jython, Groovy, PHP, JavaScript/Phobos y Scala, entre otros lenguajes.
Lo esencial: diferencias adicionales entre los contenedores Web
Además de las ventajas generales mencionadas, GlassFish se diferencia de Tomcat por las posibilidades que ofrece su contenedor Web. Le ofrecemos algunos ejemplos:

La capacidad de retener sesiones entre distintos despliegues de aplicaciones (v3 Prelude) supone un importante ahorro de tiempo para los desarrolladores que crean aplicaciones Web Java.
GGlassFish v2 y v3 Prelude facilita la reconfiguración dinámica de servidores virtuales y Listeners HTTP sin necesidad de reiniciar el servidor. Con Tomcat, cuando se modifica una fuente de recursos, suele ser necesario reiniciar el servidor de aplicaciones.
En v2 y v3 Prelude, el entorno Grizzly de alto rendimiento y alta escalabilidad mejora los tiempos de solicitud/respuesta. Las capas inferiores del nivel Web de GlassFish se implementan a través de Grizzly Framework. Este entorno está escrito en Java y aprovecha las APIs NIO (red escalable y E/S de archivos) para proporcionar escalabilidad y es altamente personalizable.
GlassFish v2 y v3 Prelude incluyen varias optimizaciones de rendimiento, como “flattened valve invocation”, una modificación de la arquitectura de válvula que racionaliza la forma de llamar a cada válvula, reduciendo así la profundidad de la pila y mejorando el rendimiento. GlassFish v3 Prelude también admite válvulas de estilo Tomcat.
Sun ha realizado pruebas exhaustivas de escalabilidad para comparar los conectores NIO de Tomcat y Glassfish. Estas pruebas utilizan un servlet simple para minimizar el tiempo dedicado en el contenedor y medir cuántas operaciones por segundo admiten los distintos contenedores para incrementar el número de usuarios. Por ejemplo, con 16,000 usuarios, el benchmark arroja los siguientes resultados:

GLASSFISH TOMCAT
Operaciones/segundo 6988,9 6615,3
Tiempo medio respuesta 0,242 0,358
Tiempo máx. respuesta 1,519 3,693
90% tiempo respuesta 0,6 0,75

Consiga todos los detalles y tome la decisión adecuada
La selección de un servidor de aplicaciones afecta a muchos aspectos de las operaciones de la empresa, no sólo a los equipos de desarrollo. Se trata de una decisión con gran carga estratégica para el negocio. Sun afirma que GlassFish ha demostrado ser una opción superior para los desarrolladores de la nueva generación. Pero le animamos a documentarse en profundidad y a sopesar detenidamente sus alternativas. Encontrará información adicional y estudios comparativos de GlassFish y Tomcat en nuestro informe técnico.

Manuales de Linux

Tomado de:

http://www.alcancelibre.org/filemgmt/