Hola Amigos:

El otro día vi un sistema de "Help Desk", por medio del cual los usuarios pueden enviar un reporte, una solicitud de servicio, etc. vía correo electrónico, a una cuenta de correo especifica, y el sistema toma la información del email, e inclusive un archivo anexo a este, y lo convierte en un registro o reporte dentro de dicho sistema.

¿Alguna idea de cómo podría capturar la información contenida en un email e ingresarla a una base de datos?

Como siempre, gracias por sus sugerencias y ayuda.

Saludos,

Caribesoft

Un mail no es más que un archivo de texto...

abre el archivo con tu editor de textos y checkea el código fuente, verás que no es muy complicado...

además seguramente haya un módulo en search.cpan.org que ya te trae la info automáticamente...

Saludos

Gracias monoswim por tu respuesta, pero sigo perdido, ¿cómo hago para capturar ese "archivo" o "email"?

Yo me refiero a que el email es enviado a través de Outlook, como un simple email, y llega al buzón de una cuenta de correo predeterminada, pero ¿cómo puedo extraer de allí ese archivo?

Saludos.

Caribesoft

Hola, lo que se me ocurre es que puedes hacerlo mediante algún módulo de Perl conectarte al servidor de correo, y bajar los correos con tu programa luego hacer la manipulación necesaria para poder guardarlo en una BD
te dejo este link tal vez te pueda ayudar para comenzar

http://perlenespanol.baboonsoftware.com ... ght=correo

Saludos

Pues eso depende del nivel de acceso que tengas a ese buzón. Lo más sencillo es imitando el acceso de un cliente de correo. Eso quiere decir que tenemos que elegir un protocolo de acceso al correo. El más famoso es POP, pero también puede ser IMAP. En CPAN hay unos cuantos módulos que permiten "hablar" con los servidores de correo, en esos protocolos, y pedirles que te entreguen el último correo o una lista de todo el correo disponible. Buscas el que te interesa y le pides que te de ese. Un ejemplo es Email::Folder::IMAP.

Naturalmente, tienes que saber el protocolo con el que tienes que hablar al servidor de correo. Y según eso eliges el módulo adecuado.

Mira el proyecto Perl Email. Vete a la sección de módulos.

Hola Explorer:

Perdón, no ha visto tu respuesta, voy a revisar este módulo que comentas.

Quisiera ver si le puedes dar un vistazo a la aplicación que te comento, (en su demo), para que veas cómo funciona, envías un email a este correo: perldesk@logicdemo.com

Y lo recibe la aplicación y lo convierte en un "Ticket".

En el siguiente link puedes ver el módulo administrativo, y el ticket recién ingresado (vía email):

http://perldesk.logicdemo.com/staff.cgi?do=listcalls&group=Today

Eso es lo que busco poder hacer...

Saludos cordiales,

Caribesoft

Depende de muchos factores... pero al final, consiste en saber dónde y en qué formato está lo que quieres leer. Si es un correo dentro de un buzón ya tienes algunas ideas. Si es un fichero de texto, pues más fácil todavía. Si es una base de datos, pues habrá que hacer una consulta.

Hola amigos,
Muy interesante la discusión en su foro,
¿Creen que sería posible crear una aplicación web que registre los correos que entran a mi servidor y los convierta en tiques?

¿Cómo podría hacer algo así ?

Si, es posible.
Solo necesitas 3 cosas.

1- Administrar el mailserver

2- Implementar una política interna de formato (es decir, como se va a escribir el mail)*

3- Parsear (transformar) los campos como variables (pe: Asunto: "Servicio de red detenido".) e insertarlos en tu database.

*Respecto al punto 2) personalmente preferiría crear un front-end, para minimizar el margen de error humano y que la aplicación pudiera funcionar con errores.

Hay varias técnicas.

* Una tarea programada o cron puede lanzar un programa que se conecte al buzón (con su protocolo, usuario y contraseña) y recupere los mensajes y los trate una o uno.

* Si se tiene acceso al servidor de correo, y éste lo permite, se puede colocar filtro de correo (como por ejemplo el procmail) que tratará cada correo a medida de que llegue.

En ambos casos, no son aplicaciones web. Sí podría serlo el programa que consulte el resultado del tratamiento.

¡ Hola colegas !

Existen una variedad de sistema de tiques, yo lo haría muy fácil.
Obtener los datos de un mail no es complicado, Uds. se refieren a cómo captar ese email.

Si utilizan un sistema pop3, recibirían los "reclamos/incidencias" (tiques), ahí solo queda aprender el protocolo de transmisión de comandos y utilizarlos.

Sería muy simple, un mail directo a la casilla o desde un webmail podrían recibir los tiques. Podrían centralizarlo en una web en la intranet en caso de ser un helpdesk on site, si trabajan para cubrir soporte móvil, igual pueden usar una web.

Yo les recomendaría que usen algún sistema open source: http://osticket.com/tour/

Y luego para organizarse internamente utilizar taskfreak.

Voy a ver si les encuentro algún otro sistema de tiques, en español sobre todo.

El tema no trata de resolver un problema de tiques, sino de hacerlo

Sí, el título del tema lo dice así.

El protocolo POP3 se refiere a la transmisión de correos desde el PostOffice (servidor de correo) hasta el gestor de correo del cliente. Pero en este caso no es necesario aprender ningún protocolo: en Perl ya existen los módulos que nos permiten dialogar con el servidor usando POP3, IMAP y otros, y entregarnos el contenido de las bandejas de entrada, la lista de mensajes, y cada correo por separado.

Sí, es lo que está comentado: un proceso periódico (como el cron, por ejemplo), lanza nuestro programa, accede al buzón, lee los mensajes, extrae la información, y crea los tiques, que, normalmente, serán guardados en una base de datos, o saldrán por pantalla, o activarán un sirena luminosa o una bocina o un motor que mueva algo.

Gracias, pero el objetivo del tema no es el uso de sistemas de tiques, sino de transformar los correos que llegan a tiques para luego mostrarlos en web.

Es claro que hay sistemas ya hechos que hacen justamente eso (recibir tiques por correo, guardarlos en la base de datos para luego ser mostrados en la web), pero aquí intentamos dar una respuesta a la gente que quiere hacérselo en lugar de depender de un producto hecho por otros (esto tiene ventajas e inconvenientes).

Las ventajas de usar un sistema prefabricado son claras: enseguida empiezas a trabajar. Solo tienes que instalarlo.

Los inconvenientes:
* debes ajustarte a su forma de trabajar
* no siempre está en tu idioma
* si es un servicio web que no puedes descargar y instalar en tu máquina, debes ajustarte a la legislación local tuya, para ver si se permite el envío de información sensible a otro país (algunas veces, no es posible)
* si hay errores en el programa, depende de si dispones del código fuente, quizás puedas arreglarlos. Sino, tendrás que informar y esperar a que los arreglen, y comenzar el proceso de instalación o actualización. Esto también quiere decir que debes estar al tanto de la presencia de esos errores. Debes suscribirte a los boletines de seguridad de la aplicación, para estar atentos de nuevos errores y correcciones.

Los más jóvenes son propensos a instalar software prefabricado, porque obtienen resultados inmediatos. Los más mayores, se piensan a veces en la posibilidad de hacerlo uno mismo, al tener la experiencia de que ese software prefabricado, en realidad, les ha llevado casi el mismo tiempo de mantenimiento, que de desarrollo.

Naturalmente, esto es mi humilde opinión, que, quizás, no sea la más correcta.

Hay casos en los cuales no vas a programar tu mismo la solución, como por ejemplo, un Office. En esa situación, no te queda más remedio que buscar una solución ya hecha (LibreOffice) o comprar una licencia de una solución cerrada (Office). Con la licencia, va incluido el compromiso de la empresa en que arreglará los errores encontrados.

En Perl, el más famoso, es el Request Tracker, de la empresa Best Practical. Es el sistema que se usa para informar de errores a los programadores que contribuyen en CPAN. Como se ve en esa primera página, se puede informar de errores desde la web, desde el correo electrónico, y a través del comando perlbug.

Y, obviamente, en CPAN, hay un montón de módulos, al respecto.

En resumidas, la idea es aportar, ya sea comentando ideas, bases o lo que salga.
En mi caso, es lo que me salió a mi.

¡¡ Saludosss !!