ES2289347T3 - Sistema y procedimiento para la generacion automatizada de archivos imprimibles a partir de datos. - Google Patents
Sistema y procedimiento para la generacion automatizada de archivos imprimibles a partir de datos. Download PDFInfo
- Publication number
- ES2289347T3 ES2289347T3 ES03785519T ES03785519T ES2289347T3 ES 2289347 T3 ES2289347 T3 ES 2289347T3 ES 03785519 T ES03785519 T ES 03785519T ES 03785519 T ES03785519 T ES 03785519T ES 2289347 T3 ES2289347 T3 ES 2289347T3
- Authority
- ES
- Spain
- Prior art keywords
- server
- printing
- data
- interface
- orders
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/12—Digital output to print unit, e.g. line printer, chain printer
- G06F3/1201—Dedicated interfaces to print systems
- G06F3/1202—Dedicated interfaces to print systems specifically adapted to achieve a particular effect
- G06F3/1203—Improving or facilitating administration, e.g. print management
- G06F3/1204—Improving or facilitating administration, e.g. print management resulting in reduced user or operator actions, e.g. presetting, automatic actions, using hardware token storing data
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/12—Digital output to print unit, e.g. line printer, chain printer
- G06F3/1201—Dedicated interfaces to print systems
- G06F3/1202—Dedicated interfaces to print systems specifically adapted to achieve a particular effect
- G06F3/1203—Improving or facilitating administration, e.g. print management
- G06F3/1205—Improving or facilitating administration, e.g. print management resulting in increased flexibility in print job configuration, e.g. job settings, print requirements, job tickets
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/12—Digital output to print unit, e.g. line printer, chain printer
- G06F3/1201—Dedicated interfaces to print systems
- G06F3/1223—Dedicated interfaces to print systems specifically adapted to use a particular technique
- G06F3/1237—Print job management
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/12—Digital output to print unit, e.g. line printer, chain printer
- G06F3/1201—Dedicated interfaces to print systems
- G06F3/1278—Dedicated interfaces to print systems specifically adapted to adopt a particular infrastructure
- G06F3/1285—Remote printer device, e.g. being remote from client or server
- G06F3/1287—Remote printer device, e.g. being remote from client or server via internet
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/12—Digital output to print unit, e.g. line printer, chain printer
- G06F3/1201—Dedicated interfaces to print systems
- G06F3/1278—Dedicated interfaces to print systems specifically adapted to adopt a particular infrastructure
- G06F3/1285—Remote printer device, e.g. being remote from client or server
- G06F3/1288—Remote printer device, e.g. being remote from client or server in client-server-printer device configuration
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Human Computer Interaction (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Accessory Devices And Overall Control Thereof (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Document Processing Apparatus (AREA)
Abstract
Sistema para la generación automática de archivos imprimibles a partir de datos de una base (30) de datos, comprendiendo dicho sistema un sistema (10) de impresión que está compuesto por al menos un componente (14) de tratamiento de la impresión, presentando el componente (14) de tratamiento de la impresión medios para imprimir y/o tratar adicionalmente los archivos imprimibles, caracterizado por las siguientes características: - el sistema (10) de impresión presenta al menos un medio (15) de generación de pedidos de impresión, siendo el medio de generación de pedidos de impresión un programa en al menos un ordenador del sistema (10) de impresión, - el medio (15) de generación de pedidos de impresión puede conectarse con un servidor (20) a través de Internet y una primera interfaz (40), siendo la primera interfaz (40) una interfaz SOAP (Simple Object Access Protocol, protocolo simple de acceso a objetos) y el servidor (20), un servidor SOAP, y la interfaz SOAP utiliza http/HTTPS como protocolo de transmisión de datos, - el servidor (20) puede conectarse con una base (30) de datos mediante una segunda interfaz (50), encontrándose la base (30) de datos por fuera del área del sistema (10) de impresión y la segunda interfaz (50) es una capa PL/SQL (Procedural Language/Structured Query Language, lenguaje procesal/lenguaje estructurado de consulta), - el medio (15) de generación de pedidos de impresión presenta medios para la solicitud y recepción de datos procedentes de la base (30) de datos, y - el medio (15) de generación de pedidos de impresión presenta medios para preparar los datos de la base (30) de datos para los requerimientos del componente (14) de tratamiento de la impresión y medios para generar archivos imprimibles.
Description
Sistema y procedimiento para la generación
automatizada de archivos imprimibles a partir de datos.
La invención se refiere a un sistema para la
generación automatizada de archivos imprimibles a partir de datos
de una base de datos, que comprende un sistema de impresión
compuesto por al menos un componente de tratamiento de la
impresión, presentando el componente de tratamiento de la impresión
medios para imprimir y/o tratar adicionalmente los archivos.
La invención se refiere además a un
procedimiento para la generación automatizada de archivos
imprimibles a partir de datos de una base de datos, en el que los
archivos los genera, imprime y/o trata adicionalmente un sistema de
impresión compuesto por al menos un componente de tratamiento de la
impresión y un medio de generación de pedidos de impresión.
La generación de archivos imprimibles está
adquiriendo una importancia creciente dado que en las más diversas
áreas de aplicación se generan de forma electrónica, se tratan
adicionalmente y se imprimen cada vez mayores cantidades de objetos
de impresión. En especial, existe la necesidad de generar envíos de
correo individualizados en vías electrónicas y, a continuación,
imprimirlos y tratarlos adicionalmente.
Por ejemplo, las empresas postales ofrecen,
además del mero envío de cartas y paquetes, numerosos servicios en
el área de cartas y mailing (publicidad por correo). En este caso,
un sistema de este tipo admite todo el proceso de elaboración para
documentos impresos y que han de enviarse. Con la importancia
creciente que está adquiriendo el correo electrónico, esto también
es válido en el área de la comunicación por correo electrónico y
los sistemas logísticos basados en Internet.
En este caso, los componentes de un sistema
concebido para este tipo de procesos sirven para diversos
objetivos. Por un lado, sirven como interfaz de entrega y sistema
de producción para envíos de cartas finalmente impresas en papel
que se entregan por correo a los destinatarios. Por otra parte,
componentes de sistema con interfaces ofrecen una posibilidad de
transmisión directa de mensajes por vías electrónicas. El envío y
la entrega pueden realizarse así por correo electrónico y a través
de protocolos Web.
El usuario debe superar algunos obstáculos
técnicos de producción para beneficiarse de estas ofertas. Esto va
desde la creación de mailing (publicidad por correo), pasando por
la creación de grupos de direcciones de destino, hasta la impresión
en serie en sí misma, incluyendo controles de calidad. Incluso con
la ayuda de proveedores de servicios especializados, tales como
Lettershops (centro de preparación de envíos postales) y centros de
impresión, la elaboración de mailing siempre se ha mostrado como un
proceso complejo. Múltiples interrupciones de medios e interfaces
heterogéneas o modos de pensar de diferentes puntos intermedios
implicados, hacen que el procedimiento sea caro y costoso para
pequeños números de envíos. Para grandes mailing es técnicamente
complejo y requiere mucho tiempo.
Para la impresión y el tratamiento adicional de
pedidos de impresión dentro de un sistema de impresión se utilizan
normalmente diferentes componentes de tratamiento de la impresión
tales como impresoras, sistemas de clasificación y ensobrado u
otros dispositivos de tratamiento. Con esto se producen numerosas
posibilidades de combinación de hardware y procesos de trabajo que
requieren en cada caso un tratamiento especial de la impresión.
En el estado de la técnica se conocen
procedimientos de tratamiento de la impresión para los más diversos
requisitos. El documento de patente alemán DE 199 21 120 C2
describe, por ejemplo, un procedimiento y un sistema para la
imposición de datos de impresión en un sistema PED (Print On Demand,
impresión a petición). En este caso, se refiere a la impresión y
plegado de pliegos de impresión en los que las imágenes de
impresión de páginas continuas se disponen ajustadas exactamente
unas a otras.
Del documento de patente DE 100 17 785 C2 se
conoce además un procedimiento y un sistema para el tratamiento de
una corriente de datos, en el que la corriente de datos se prepara
para la salida en un aparato de impresión. En este caso, una
corriente de datos de impresión que se presenta en un primer
formato de datos de impresión se transforma a un formato de datos
normalizado, y la corriente de datos de impresión transformada de
esta manera se indexa mediante criterios de indexación
predeterminados. La corriente de datos de impresión indexada se
clasifica entonces mediante parámetros de clasificación en una
secuencia de clasificación y la corriente de datos de impresión
clasificada se emite para el tratamiento adicional, especialmente
para la impresión.
En la práctica, a menudo se presenta el problema
de que los pedidos de impresión se transmiten a diferentes sistemas
de impresión, requiriendo los sistemas de impresión en cada caso
una preparación diferente de los datos. Este es especialmente el
caso cuando, por ejemplo, una empresa de correo contrarresta datos
para pedidos de impresión de usuarios de un sistema de servicio
concebido para esto, los almacena en una base de datos central y
transmite la implementación de los pedidos de impresión a
componentes de sistema o proveedores de servicios de impresión
propios. Cada proveedor de servicios de impresión dispone
normalmente de un sistema de impresión específico para él con
diferentes componentes de hardware y software. Para preparar
unitariamente los pedidos de usuario tras la recepción de los datos
por parte de las empresas postales y transmitirlos como pedidos de
impresión terminados al sistema de impresión correspondiente del
proveedor de servicios, en las empresas postales es necesario el
conocimiento de todas las especificaciones de los proveedores de
servicios de impresión implicados. Esto requiere a su vez un gasto
considerable en hardware y software por parte de la empresa
postal.
La publicación alemana para información de
solicitud de patente DE 198 17 878 A1 da a conocer en relación con
esto, por ejemplo, un procedimiento y un dispositivo para la
fabricación, envoltura y ensobrado de envíos de impresión. En este
caso, se generan datos de impresión, en el caso de un cliente de un
pedido de impresión, y se transmiten a través de una red a un
dispositivo de impresión en el que se imprimen los datos de
impresión transmitidos. El cliente elabora el pedido de impresión
en su ordenador personal, que está conectado con uno o varios
ordenadores centrales. Los ordenadores centrales están conectados
con servidores que pueden encontrarse, por ejemplo, en diferentes
ciudades o países. El cliente elige un servidor con capacidad de
impresión libre y le transmite a éste el pedido de impresión. Este
pedido de impresión se desarrolla de forma totalmente automática en
el servidor seleccionado, presentando el servidor preferiblemente
otro ordenador personal y un dispositivo de impresión. El pedido de
impresión se almacena en el ordenador personal y éste controla el
dispositivo de impresión con diversos componentes tales como rollos
de papel, máquinas de encolado, unidades de impresión, unidades de
corte, unidades de envoltura y plegado.
La publicación alemana para información de
solicitud de patente DE 101 23 488 A1 describe además un sistema de
impresión para la impresión de una pluralidad de pedidos en un
sistema con una pluralidad de estaciones de tratamiento. Cada una
de las estaciones de tratamiento se utiliza para disponer los
documentos en un formato de archivo preparado para la impresión y
elaborar un Job Ticket (ticket de trabajo) electrónico que contiene
propiedades globales del documento. En este caso, un cliente
transmite al sistema de impresión un pedido de objetos que han de
imprimirse directamente en formato papel, en un soporte de datos o
a través de Internet.
La publicación alemana para información de
solicitud de patente DE 101 22 880 A1 da a conocer un procedimiento
para generar automáticamente instrucciones de impresión. Para esto,
un usuario introduce instrucciones en un ordenador para que el
ordenador coloque en una carpeta electrónica una pluralidad de
documentos recibidos y disponga los documentos en la carpeta en el
orden deseado para el producto final impreso. La transmisión del
pedido de un cliente al sistema de impresión también se realiza en
este caso enviando un pedido de los objetos que han de imprimirse
directamente en formato papel, en un soporte de datos o a través de
Internet.
De la solicitud de patente internacional WO
02/21293 se conoce un sistema en el que un servidor recibe a través
de Internet datos de un usuario y los almacena temporalmente en una
base de datos. A continuación, la base de datos consulta estos
datos de usuario y los introduce en un documento maestro como
metadatos. Estos metadatos ya han sido tratados antes del
almacenamiento en la base de datos de forma correspondiente a su
tratamiento posterior como metadatos que van a añadirse.
De la solicitud de patente internacional WO
01/61466 A1 se conoce además un sistema para la generación de
documentos, en el que el sistema está configurado como servicio de
Internet y se permite a un cliente utilizar modelos estandarizados
para la elaboración de documentos. En este caso, varios clientes
con navegadores pueden rellenar formularios mediante una aplicación
de Internet y los pedidos generados de esta manera se almacenan en
una base de datos en conexión con un servidor Web. Diferentes
programas de tratamiento de texto procesan los pedidos y los
documentos generados se transmiten al cliente o a un destinatario
determinado. En caso de que las capacidades del servidor Web no
sean suficientes para el tratamiento del pedido, pueden emplearse
unidades suplementarias mediante una red LAN. En este caso, las
unidades suplementarias acceden mediante componentes Ethernet
estándar a una lista de trabajo del servidor Web y replican en cada
caso una parte del servidor Web.
La invención se basa en el objetivo de crear un
sistema que permita a un sistema de impresión recibir datos de una
base de datos por fuera del área del sistema de impresión y, a
partir de estos datos, en función de los requisitos específicos del
sistema de impresión, generar archivos imprimibles de forma
automatizada, procediendo los datos de la base de datos de usuarios
de un sistema de servicio, por ejemplo, una empresa de correo, a la
que se le han encargado pedidos de impresión para mailing.
El objetivo de la invención es además facilitar
un procedimiento para la generación automatizada de pedidos de
impresión a partir de datos de una base de datos mediante un
sistema de impresión, en el que la base de datos se encuentra fuera
del área del sistema de impresión, procediendo los datos de la base
de datos de usuarios de un sistema de servicio, por ejemplo, una
empresa postal, que han encargado pedidos de impresión para
mailing.
Según la invención, este objetivo se consigue
gracias a un sistema con las características de la reivindicación
1. El objetivo se consigue además gracias a un procedimiento con
las características de la reivindicación 2, representando el objeto
de las reivindicaciones 3 - 4 dependientes formas de realización
especialmente ventajosas del procedimiento según la invención.
La invención comprende un sistema para la
generación automatizada de archivos de datos imprimibles de una
base de datos, que comprende un sistema de impresión compuesto por
al menos un componente de tratamiento de la impresión, presentando
el componente para el tratamiento de la impresión medios para
imprimir y/o tratar adicionalmente los archivos, y el sistema
comprende las siguientes características:
- -
- el sistema de impresión presenta al menos un medio de generación de pedidos de impresión,
- -
- el medio de generación de pedidos de impresión puede conectarse con un servidor a través de una primera interfaz,
- -
- el servidor puede conectarse con una base de datos a través de una segunda interfaz,
- -
- el medio de generación de pedidos de impresión presenta medios para solicitar y recibir datos de la base de datos, y
- -
- el medio de generación de pedidos de impresión presenta medios para la preparación de datos de la base de datos para los requerimientos del componente de tratamiento de la impresión y medios para generar archivos imprimibles.
El objetivo se consigue además gracias a un
procedimiento para la generación automatizada de archivos
imprimibles a partir de datos de una base de datos, en el que se
generan, imprimen y/o tratan adicionalmente los archivos de un
sistema de impresión que se compone de al menos un componente de
tratamiento de la impresión y un medio de generación de pedidos de
impresión, y el procedimiento comprende las siguientes etapas:
- -
- el medio de generación de pedidos de impresión genera un primer mensaje que incluye una llamada a un servidor para un determinado método con parámetros,
- -
- el medio de generación de pedidos de impresión establece una conexión con el servidor a través de una primera interfaz,
- -
- el medio de generación de pedidos de impresión transmite al servidor el primer mensaje a través de la primera interfaz,
- -
- el servidor trata este primer mensaje solicitando el método determinado con los parámetros correspondientes,
- -
- el servidor establece una conexión con la base de datos a través de una segunda interfaz,
- -
- el servidor solicita datos de la base de datos a través de la segunda interfaz,
- -
- el servidor devuelve el resultado de la llamada del método determinado en forma de un segundo mensaje al medio de generación de pedidos de impresión, y
- -
- el medio de generación de pedidos de impresión genera al menos un archivo imprimible a partir del resultado de la solicitud del método determinado.
El sistema de impresión es, por ejemplo, un
sistema de un proveedor de servicios de impresión, que comprende
impresoras, instalaciones de clasificación y ensobrado y/u otros
aparatos de tratamiento. Dentro de un sistema de impresión de este
tipo está instalado según la invención un elemento para la
generación de pedidos de impresión que puede conectarse con un
servidor. El servidor puede conectarse a su vez con una base de
datos que contiene datos para las impresiones que van a realizarse.
La base de datos se encuentra fuera del sistema de impresión y
comprende normalmente grandes volúmenes de datos. Estos datos
proceden, por ejemplo, de usuarios de un sistema de servicio de una
empresa postal que han encargado pedidos de impresión para
mailing.
El medio de generación de pedidos de impresión
según la invención es normalmente un programa que preferiblemente
está instalado en ordenadores del sistema de impresión. El concepto
"ordenador" no ha de entenderse en este caso de forma
limitante en ningún modo. En este caso, puede tratarse de una unidad
cualquiera adecuada para la realización de cálculos, por ejemplo,
una estación de trabajo, un ordenador personal, un microordenador o
un circuito adecuado para la realización de cálculos y lo
comparaciones.
En un ejemplo de realización especialmente
preferido de la invención, el medio de generación de pedidos de
impresión puede conectarse a modo de una primera interfaz mediante
una interfaz SOAP con un servidor SOAP. La sigla SOAP significa
Simple Object Access Protocol (protocolo simple de acceso a
objetos). SOAP es un protocolo de comunicación para el acceso a
módulos individuales de programas en Internet. SOAP es un protocolo
delgado con el que pueden empaquetarse módulos propietarios y
pueden dotarse de interfaces comprensibles en general. SOAP
determina cómo se realiza una llamada de funciones con datos XML a
través de plataformas informáticas (Remote Procedure Call, llamada
de procedimiento remoto). Resulta ventajosa una conexión al
servidor a través de Internet, sin embargo, también son posibles
otras conexiones. En este caso puede tratarse de conexiones fijas
o
temporales.
temporales.
El servidor puede conectarse, según la
invención, a través de una segunda interfaz con al menos una base
de datos. En un ejemplo de realización especialmente preferido de
la invención, se emplea para la conexión entre el servidor y la
base de datos una capa PUSQL. La sigla PUSQL significa Procedural
Language / Structured Query Language (lenguaje procesal / lenguaje
de consulta estructurado). Se trata de un lenguaje de programación
propietario, por ejemplo, para Oracle, que añade estructuras
procesales y posibilidades de control al lenguaje SQL no procesal.
Mediante el servidor se transmiten al medio de generación de
pedidos de impresión datos procedentes de la base de datos que
contienen, por ejemplo, modelos, datos variables, instrucciones de
personalización y otra información relativa a los pedidos de
impresión que van a elaborarse.
El medio de generación de pedidos de impresión
elabora pedidos de impresión a partir de los datos recibidos y
genera a partir de éstos archivos imprimibles de forma
automatizada. El medio de generación de pedidos de impresión
describe en este caso cómo han de prepararse los archivos para una
determinada combinación de papel / hardware. Esto comprende, por
ejemplo, páginas de información para el personal, códigos de
control para un sistema de ensobrado, marcas de corte, formatos de
papel, la generación de tickets RIP para impresoras, códigos de
control SDL, instrucciones de ensobrado e instrucciones acerca de
cómo se transportan los datos a una impresora.
Los datos en la base de datos representan
pedidos de usuarios para la impresión de envíos postales. En lo
sucesivo se denomina a los pedidos de los usuarios UserJobs,
mientras que los pedidos de impresión que resultan de éstos se
denominan PrintJobs. Dado que los UserJobs generados por usuarios
pueden tener tamaños muy diferentes, y los PrintJobs para una
producción óptima no deberían ser ni demasiado pequeños ni
demasiado grandes, ha resultado ser ventajoso dividir los pedidos
grandes y/o unir varios pedidos pequeños para formar grandes. Se
prefiere especialmente en relación con esto la implementación de un
mecanismo que divida automáticamente pedidos grandes.
Otras preferencias, particularidades y variantes
convenientes de la invención se desprenden de las reivindicaciones
secundarias y de la siguiente representación de ejemplos de
realización preferidos mediante las figuras.
Las figuras muestran
la figura 1, la estructura esquemática de un
sistema para la generación automatizada de archivos
imprimibles;
la figura 2, una representación metódica de una
llamada a un servidor SOAP;
la figura 3, una representación metódica de una
llamada a un servidor SOAP por SOAP;
la figura 4, una representación detallada de una
llamada a un servidor SOAP a través de una interfaz Apache SOAP
API;
la figura 5, la representación de una clase de
servidor proxy.
En la figura 1 se muestra de forma esquemática
la estructura del sistema para la generación automatizada de
archivos imprimibles mediante un ejemplo de realización
especialmente preferido. Un sistema 10 de impresión presenta según
la invención un medio 15 de generación de pedidos de impresión. El
sistema de impresión se encuentra, por ejemplo, en un proveedor de
servicios de impresión que forma parte de un sistema de mailing, en
el que el sistema de mailing recibe datos electrónicos de usuarios,
los prepara y, por ejemplo, los trata adicionalmente para formar
cartas, postales y/o correos electrónicos. Los datos de usuarios y
pedidos correspondientes se depositan de forma conveniente en una
base 30 de datos que se encuentra fuera del área del sistema de
impresión.
Los proveedores de servicios de impresión
presentan normalmente diferentes sistemas de impresión con
requisitos específicos para diferentes componentes 14 de tratamiento
de la impresión, pudiendo comprender los componentes de tratamiento
de la impresión, por ejemplo, impresoras 11, instalaciones 12 de
clasificación y/o instalaciones 13 de ensobrado. Por tanto, para la
preparación específica de datos en el ámbito del sistema 10 de
impresión según la invención se emplea un medio 15 de generación de
pedidos de impresión. El medio 15 de generación de pedidos de
impresión es normalmente un programa que normalmente está instalado
en uno o varios ordenadores del sistema 10 de impresión.
Para permitir al medio 15 de generación de
pedidos de impresión y, con ello, al sistema 10 de impresión acceso
a los contenidos de una base 30 de datos fuera del área del sistema
de impresión y para automatizar estas etapas, en un ejemplo de
realización especialmente preferido de la invención se ha elegido
una arquitectura cliente - servidor en la que se utiliza SOAP como
medio de comunicación a través de Internet. El medio 15 de
generación de pedidos de impresión está unido para esto mediante
una primera interfaz 40 SOAP con un servidor 20 SOAP fuera del área
del sistema de impresión. Esta primera interfaz se genera
preferiblemente a través de Internet 60. Sin embargo, también pueden
elegirse otros tipos de conexión que pueden ser conexiones
temporales o fijas.
Una interfaz SOAP presenta, en comparación con
protocolos de comunicación propietarios tales como CORBA (Common
Object Request Broker Architecture, arquitectura común de
intermediarios en peticiones a objetos) o RMI (Remote Methode
Invocation, llamada de método remoto), por ejemplo, la ventaja de
que durante la transmisión de datos no se presentan conflictos con
un firewall (cortafuegos) del medio 15 de generación de pedidos de
impresión y/o del sistema 10 de impresión. SOAP emplea en este caso
como protocolo de transmisión de datos preferiblemente http/https.
HTTP/HTTPS se admite en una gran parte de los firewall o está
tunelado mediante proxys, de modo que no es necesaria una
adaptación a los firewall y no se crean nuevos puntos de acceso.
Mediante el uso de un protocolo SOAP que emplea como protocolo de
transporte básico el protocolo http, es posible además una
transmisión sencilla a través de Internet.
Mediante la interfaz 40 SOAP se facilitan todos
los métodos que el medio 15 de generación de pedidos de impresión
necesita para la obtención de toda la información necesaria para un
pedido de impresión de la base 30 de datos. De forma conveniente,
el sistema se protege frente al acceso de terceros. La protección
puede realizarse de diferentes maneras. Por ejemplo, puede
utilizarse una autentificación del medio 15 de generación de
pedidos de impresión en el servidor 20. Además, resulta ventajoso
el uso de https (http seguro) como protocolo de transmisión.
En un ejemplo de realización especialmente
preferido de la invención, los accesos del servidor 20 SOAP a la
base 30 de datos se realizan mediante una capa 50 PUSQL. Con esto
es posible, entre otras cosas, protocolizar todos los accesos a la
base de datos o ajustar determinados atributos. Esto tiene la
ventaja de que puede garantizarse una consistencia de la base de
datos.
Se ha mostrado conveniente realizar todos los
cambios de estado sin conexión a Internet en el medio de generación
de pedidos de impresión y enviar a continuación los cambios
realizados al servidor. Esto tiene la ventaja de que el medio de
generación de pedidos de impresión sólo debe disponer de una
conexión temporal a Internet y también puede trabajar sin conexión
permanente a Internet. Solamente debe establecerse una conexión a
Internet para el ajuste con el servidor.
Además, una ventaja del sistema según la
invención es que pueden almacenarse de forma central en el servidor
actualizaciones para la configuración del medio de generación de
pedidos de impresión. En un ejemplo de realización especialmente
preferido de la invención, el medio de generación de pedidos de
impresión comprueba al inicio si existen actualizaciones y actualiza
su configuración automáticamente a través de JavaWebStart desde el
servidor central.
Además, resulta especialmente ventajoso
desarrollar la verdadera comunicación mediante SOAP por una
interfaz Apache SOAP API. La sigla API corresponde a Application
Programming Interface (interfaz de programación de aplicaciones),
que es una interfaz predeterminada por un sistema operativo o un
programa de aplicación, mediante la cual se facilitan a otras
aplicaciones herramientas de software estandarizadas. Por tanto,
una interfaz API posibilita a un programa de aplicación utilizar
funciones y/o servicios de otro software. Al contrario que una
interfaz de archivos, una interfaz API es una denominada interfaz
Call (llamada). Las ventajas en el uso de una interfaz API están,
por ejemplo, en la reducción del coste de programación y una
interfaz de usuario y un modo de funcionamiento unitarios.
En la figura 2 se muestra un ejemplo de
realización de un desarrollo metódico en el que el medio 15 de
generación de pedidos de impresión llama a un método en el servidor
20 y, tras la realización satisfactoria del método, se recibe un
resultado como valor de retorno.
Las llamadas de métodos por SOAP se representan
como mensajes XML que se envían mediante http. La figura 3 muestra
el desarrollo esquemático de una llamada de este tipo. El medio 15
de generación de pedidos de impresión genera un primer mensaje 16
SOAP en el que se indica qué método debe llamarse con qué
parámetros. Este mensaje SOAP se transmite entonces con ayuda del
protocolo http a través de Internet 60 al servidor 20 SOAP. Éste
valora las informaciones y datos y devuelve entonces un resultado
como segundo mensaje 17 SOAP.
En la figura 4 se muestra en detalle a modo de
ejemplo la llamada SOAP con ayuda de la interfaz Apache SOAP API.
El medio de generación de pedidos de impresión genera una instancia
de la clase Call de la interfaz Apache SOAP API y ajusta primero
determinadas propiedades de este objeto. En la figura 3 se muestran
a modo de ejemplo diferentes métodos que llama el medio 15 de
generación de pedidos de impresión.
Un método
TargetObject-URI corresponde, por ejemplo, a
un identificador URI inequívoco que está asignado en el lado del
servidor en el router RPC a un determinado objeto (en el caso del
ejemplo, el servidor SOAP).
Un método mapTypes se llama
preferiblemente varias veces para poder transmitir así clases
propias (por ejemplo, UserJob, User) a través de SOAP.
Mediante un método setMethodName puede
determinarse el nombre del método y ajustarse mediante
setParams una lista de los valores de parámetros.
Un método invoke se encarga entonces de
la llamada en sí misma por SOAP. Se genera un primer mensaje 16 y
se envía por http al servidor 20.
Se ha mostrado conveniente que en lados del
servidor 20 primero un servidor 21 Web acepte la consulta y la
valore. El servidor Web puede ser, por ejemplo, Tomcat. Para
posibilitar una llamada SOAP satisfactoria, debe estar asignado a
un localizador URL enviado el servlet rperouter de la interfaz
Apache SOAP API que conoce el objeto Server-SOAP. A
este servlet se transfiere la llamada. La sigla URL corresponde a
Uniform Ressource Locator (Localizador Uniforme de Recursos).
Mediante un localizador URL pueden direccionarse de forma
inequívoca todos los documentos de Internet.
A continuación, el servlet rperouter analiza el
mensaje SOAP, determina la clase que ha de llamarse y la
personaliza. Después se llama al método deseado con los parámetros
transferidos. El valor de retorno posible se transforma entonces a
su vez en un segundo mensaje 17 SOAP y este se devuelve como
respuesta por http. El objeto 18 Call en el lado del cliente analiza
este mensaje y devuelve el resultado originado al medio 15 de
generación de pedidos de impresión. En caso de fallo, puede
consultarse aquí, dado el caso, un objeto Failure (fallo).
Si un medio 15 de generación de pedidos desea
llamar a un método en el servidor SOAP, entonces, en otro ejemplo
de realización especialmente preferido de la invención, puede
utilizar una clase de servidor proxy. Un servidor proxy recibe
requisitos de un cliente, en caso necesario los modifica, y los
devuelve al objetivo original.
Un desarrollo de este tipo se muestra en la
figura 5. El servidor proxy 22 encapsula la interfaz Apache SOAP
API y ofrece al medio de generación de pedidos de impresión todos
los métodos del servidor. Una llamada de un método de este tipo se
transmite entonces mediante la interfaz Apache API y se devuelve a
su vez el valor de retorno.
Se analiza el mensaje de respuesta SOAP y
\bullet en caso de error, se arroja una
excepción o
\bullet en caso de éxito, se devuelve el
resultado.
Los métodos correspondientes transforman
entonces tipos de datos primitivos que se devuelven como objetos en
el tipo de dato primitivo correspondiente y después lo devuelven.
Por tanto, para el medio de generación de pedidos de impresión
correspondiente, la comunicación SOAP no es transparente, sino que
el servidor proxy 22 se comporta (hasta las duraciones más largas
de los métodos) como si llamara a métodos locales.
Para la comunicación, en un ejemplo de
realización especialmente preferido de la invención, se elige el
protocolo RPC (Remote Procedure Call, llamada de procedimiento
remoto). El protocolo RPC garantiza una llamada de funciones
remota. Cada servidor de una red facilita en el marco de este
concepto una pluralidad de servicios que pueden solicitarse con
RPC. Estas funciones se realizan como procedimientos de un programa
y pueden hacerse reaccionar indicando la dirección del servidor, el
número de programa y el número de procedimiento. RPC ofrece la
posibilidad de transmitir de forma sencilla llamadas de métodos y
sus parámetros. La transmisión de todos los árboles XML como
parámetro o valor de retorno no se especifica con esto. En el caso
del servidor SOAP, se utiliza preferiblemente una ampliación de la
interfaz SOAP-API de Apache que determina cómo
pueden transmitirse los árboles XML mediante el SOAP RPC. Así,
pueden transmitirse UserJobs como parámetros de método mediante la
interfaz Apache
SOAP-Api.
SOAP-Api.
El protocolo SOAP RPC ofrece además la
posibilidad de transmitir tipos de datos sencillos como cadena o
entero. No obstante, también pueden transmitirse tipos de datos
complejos en Structs o Arrays, que se componen a su
vez de tipos de datos sencillos.
Durante la comunicación entre el medio 15 de
generación de pedidos de impresión y el servidor 20 se transmiten
normalmente diferentes tipos de datos complejos (por ejemplo,
LogicalProduct, User, UserJob). Para poder transmitirlos en el
protocolo SOAP RPC, se implementan métodos de forma conveniente que
transforman las clases como SOAP-Structs y a la
inversa (serializar/deserializar). Sin embargo, la interfaz Apache
SOAP-API simplifica este paso facilitando una clase
que ofrece esta funcionalidad para todas las clases que cumplen una
especificación JavaBeans. Por tanto, las tres clases de datos se
implementan de forma conveniente mediante la especificación
JavaBeans y, por tanto, pueden transmitirse de forma sencilla
mediante la interfaz SOAP-API. JavaBeans es un
modelo de componente portátil independiente de la plataforma escrito
en Java.
A continuación, se muestra a modo de ejemplo un
ejemplo de realización especialmente preferido de un medio de
generación de pedidos de impresión que está instalado en un sistema
de impresión. De forma especialmente ventajosa, la realización del
medio de generación de pedidos de impresión es en forma de una
configuración XML. Con una configuración de este tipo puede
controlarse todo el desarrollo de la producción durante la
impresión. El manejo se realiza de forma conveniente mediante una
interfaz gráfica de usuario, mediante la cual, por ejemplo, se
inician y se introducen parámetros. Los archivos imprimibles pueden
transmitirse de forma automatizada a una impresora de
producción.
Mediante el medio de generación de pedidos de
impresión, un sistema de impresión puede transferir, por ejemplo,
pedidos asignados a él desde un sistema de mailing a sistemas
locales propios, así como acusar recibo del estado del tratamiento
al sistema de mailing. El elemento para la generación de pedidos de
impresión percibe al mismo tiempo como aplicación local la función
central de la preparación de los datos de impresión. La preparación
de los datos de impresión puede comprender, por ejemplo, las
siguientes funciones:
- -
- Preparación de datos de pedidos en el formato XML para formar trabajos de impresión específicos en cuanto a las máquinas de impresión y el acabado con un rendimiento optimizado.
- -
- Agrupación de trabajos de impresión individuales.
- -
- Transformación de trabajos de impresión a otros formatos si una máquina de impresión requiere dicho formato.
- -
- Dotar a los trabajos de impresión de códigos de control específicos de las máquinas para el tratamiento automatizado. En este caso pueden ser, por ejemplo, códigos de barras.
- -
- Generación de reimpresiones para, en caso de fallos de la producción, permitir el tratamiento posterior de envíos individuales.
La configuración del medio de generación de
pedidos de impresión está compuesta de forma conveniente de
módulos, impresoras virtuales y Settings (ajustes).
En los Settings se configuran ajustes generales
tales como, por ejemplo, rutas y parámetros de comunicación. Los
parámetros pueden modificarse mediante una interfaz de usuario del
medio de generación de pedidos de impresión. En la siguiente tabla
se muestra un listado a modo de ejemplo del significado / función
de algunos parámetros de Setting posibles:
\vskip1.000000\baselineskip
Para elaborar archivos imprimibles a partir de
un archivo XML PrintJob se ha mostrado conveniente prever un kernel
PDF (núcleo PDF). La forma en la que se producen los archivos
imprimibles se describe mediante un lenguaje de configuración. Al
kernel sólo le comunica la interfaz un archivo XML PrintJob y una
impresora virtual que va a utilizarse.
El componente de pedidos de impresión recibe
para generar datos de impresión datos de pedido que están
compuestos, por ejemplo, por una plantilla en formato PDF y datos
variables para la personalización y
meta-informaciones en formato XML. Con ayuda de una
biblioteca PDF externa que puede encontrarse, por ejemplo, en la
base 30 de datos, el medio de generación de pedidos de impresión
genera finalmente archivos PDF acabados. El tipo de generación
depende de los datos de pedido y de la
meta-información dependiente del hardware, tal
como, por ejemplo, el tamaño de los trabajos de impresión, la
clasificación según criterios postales, instrucciones de
acompañamiento para la entrega postal y/o suplementos. Además, se
realiza en función de meta-informaciones específicas
del hardware tales como imposición, optimización del rendimiento
y/o códigos de barras específicos que están configurados en las
impresoras virtuales.
El tipo de generación depende además de cómo
está definido el tratamiento. Por tanto, el medio de generación de
pedidos de impresión es también un intérprete que obtiene su lógica
a partir de un archivo de tratamiento, preferiblemente en formato
XML. Si un medio de generación de pedidos de impresión debe poder
elaborar, por ejemplo, en lugar de tarjetas postales, tarjetas de
felicitación plegables con un escrito por un lado, sólo debe
adaptarse el archivo de tratamiento. Esto sucede en el punto
central del sistema de mailing y, en el siguiente reinicio, se
transmite el cambio automáticamente al medio de generación de
pedidos de impresión de modo que el medio de generación de pedidos
de impresión puede elaborar entonces tarjetas de felicitación con
una inscripción por un lado.
Las posibilidades de producir un documento son
muchas y dependen de diversos factores tales como el formato de
partida, los colores que se desea, el formato de papel que va a
imprimirse, el tratamiento final y las impresoras utilizadas. Para
describir cómo ha de producirse un documento para un caso concreto
se introduce el concepto "impresora virtual". Una impresora
virtual describe en este caso bajo qué condiciones puede producirse
con ésta un documento y cómo se prepara el documento para este caso
concreto.
Es posible que con la misma impresora virtual
puedan producirse diferentes documentos, por ejemplo, podrían
elaborarse tanto documentos en color como en blanco y negro con la
misma preparación con una impresora de color. Es posible que
diferentes impresoras virtuales utilicen la misma impresora física
para la impresión, por ejemplo, pueden imprimirse documentos con el
formato de partida DIN A4 tanto en DIN A4 como también en DIN A3
con el subsiguiente tratamiento final. Los dos casos requieren
diferente preparación de los archivos y, por tanto, deben
prepararse con diferentes impresoras virtuales. Sin embargo, las dos
impresoras virtuales pueden enviar los archivos a la misma
impresora física si puede imprimir DIN A4 y DIN A3.
Las impresoras virtuales se generan en la
configuración y las trata gradualmente el kernel PDF durante una
producción de PrintJob.
Al comienzo de la producción se le comunica al
kernel la impresora virtual que va a utilizarse. Después se lee el
archivo XML del PrintJob, a partir del cual se construyen las
estructuras internas de datos que son necesarias para el resto de
la producción.
Durante toda la producción, el kernel de
producción percibe qué página de la carta se encuentra sobre las
páginas elaboradas del documento PDF. Con una función
CreateTemplatePDF puede elaborarse la parte estática para la
producción. Para esto deben personalizarse páginas vacías. Si se
imponen estas páginas personalizadas, el kernel percibe dónde se
colocan las cartas individuales. El archivo PDF personalizado puede
modificarse según se desee. Entre las opciones posibles están, por
ejemplo, la adición de páginas, la modificación del orden de las
páginas, la adición de textos y líneas y la imposición. Sólo los
archivos en los que se ha realizado la imposición no tienen que
someterse nuevamente a este proceso. Si el archivo PDF
personalizado (parte variable) está totalmente procesado, con
CreateTemplatePDF puede elaborarse un archivo PDF estático
que se adapta a éste. En este caso, a partir del modelo PDF de todos
los UserJobs se elabora un archivo FDP en el que se encuentran
todas las combinaciones necesarias. Para la elaboración posterior
de un Job-Ticket para una impresora de producción
se construye una estructura de datos que describe que página
variable se adapta a qué página estática.
Atributos de CreateTemplatePDF son, por
ejemplo, los siguientes:
\vskip1.000000\baselineskip
Una función Condition puede utilizarse
como atributo en algunas funciones para que puedan realizarse en
determinadas condiciones. Las siguientes 20 instrucciones
caracterizan Condition: "AddText", "AddLine" y
"NewPDF". Mediante la indicación de una palabra clave puede
especificarse la condición en la que debe realizarse la
instrucción.
Pueden implementarse, por ejemplo, las
siguientes palabras clave:
\vskip1.000000\baselineskip
Dentro de una función SendToPrinter puede
elaborarse un ticket Rip que transforma archivos PDF y envía los
archivos terminados a una impresora.
Con una función CreateRipTicket se
configura cómo ha de elaborarse un ticket Rip. Como atributo debe
ajustarse el nombre de archivo con el nombre destino. Dentro de
CreateRipTicket se elaboran, agrupadas con DataLines (líneas
de datos), varias descripciones Line. Dentro de Line
se ajusta el atributo Data. Todos los textos de Line
se escriben sucesivamente en el archivo Rip-Ticket.
En este caso se sustituyen las variables indicadas. En cualquier
punto pueden incorporarse bucles Repeat y Loop.
En un UserJob con ID 10000105 en el que se
forman ocho páginas PDF variables, se origina, por ejemplo, el
siguiente archivo Rip-Ticket:
\vskip1.000000\baselineskip
Con una función Convert pueden
convergerse los archivos PDF, por ejemplo, en un formato tal como
Postscript. Posibles atributos de Convert son los
siguientes:
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
Con una etiqueta NewPS se indica al medio
de generación de archivos de impresión que convierta un archivo
PDF, por ejemplo, según PostScript. Las etiquetas son códigos
limitadores para indicaciones de instrucciones en HTML. Un atributo
de NewPS en Convert puede ser
InputFilename:
\vskip1.000000\baselineskip
\newpage
Con una función Sendfile pueden enviarse
archivos directamente a una impresora. Los siguientes pueden ser
atributos de Sendfile:
En la configuración del medio de generación de
pedidos de impresión pueden registrarse tantas impresoras virtuales
como se desee. En una impresora virtual se configura qué trabajos
pueden procesarse con esta impresora virtual y cómo deben
elaborarse los documentos. Una impresora virtual tiene, por ejemplo,
la siguiente estructura:
Los atributos de VirtualPrinter pueden
tener, por ejemplo, la siguiente forma:
Mediante PrintJobConditions puede
regularse qué Jobs pueden producirse con esta impresora virtual.
Aquí pueden indicarse pares Name - Value (nombre - valor), debiendo
corresponder el nombre a un atributo UserJob. El valor en Value
indica qué valor debe tener el atributo para que pueda producirse el
UserJob con esta impresora virtual. Si no se cumple una condición,
el UserJob no puede producirse con esta impresora virtual. Pueden
ser atributos UserJob que no se han indicado en las
PrintJobConditions los que se desee.
Dentro de PrepareJobDocuments pueden
registrarse cuantas etapas PrepareDocumentSteps se desee. Estas
etapas se ejecutan de forma sucesiva para producir los
documentos.
Dentro de PrepareDocumentStep se describe
cómo se elabora un documento PDF. Este documento también puede
utilizarse como modelo en otras etapas. Dentro de
PrepareDocumentStep pueden utilizarse Loop,
Repeat y NewPDF. También puede indicarse un módulo
cuyo contenido se implementa de la siguiente manera:
También en el nivel de settings y
VirtualPrinter pueden registrarse módulos. A éstos pueden
hacer referencia varias entradas PrepareDocumentStep en
diferentes impresoras virtuales.
Dentro de un bucle Loop se repiten todas
las instrucciones allí incluidas. El número de repeticiones se
ajusta según el ajuste AddressPerPly en la impresora virtual
y según el número de direcciones en el PrintJob (NumberOfPieces). El
bucle se repite con la frecuencia a la que se adapta
AddressesPerPly en NumberOfPieces De forma
conveniente, se redondea en caso de un resto.
Loop se utiliza, por ejemplo, para
realizar un "Jobsplitting oculto". En caso de un ciclo Loop se
ajusta una variable LoopNo en cada etapa. Esta variable
puede utilizarse para generar diferentes nombres de documentos.
Repeat puede utilizarse para realizar
instrucciones varias veces. Al número de instrucciones puede
aplicarse parámetros. Durante el proceso se ajusta la variable
RepeatNo. Los atributos de Repeat son, por ejemplo,
los siguientes:
Con NewPDF puede elaborarse un nuevo
documento PDF. Dentro de NewPDF deben implementarse
instrucciones de cómo debe elaborarse el documento PDF. Las
siguientes instrucciones son posibles, por ejemplo, dentro de
NewPDF: "Repeat", "Workflow",
"PersonalizeOnTemplate", "Personalize",
"CreateTemplatePDF" y "OpenPDF".
NewPDF puede tener los siguientes atributos:
\vskip1.000000\baselineskip
Se ha mostrado especialmente ventajoso utilizar
Workflows (flujos de trabajo) en los que se describe cómo ha de
elaborarse un documento. Dentro de los Workflows pueden estar
permitidos, por ejemplo, VariableData, Merge e
Impositioning. Workflow no tiene de forma conveniente ningún
atributo. Si se disponen sucesivamente varios Workflows, entonces
éstos se procesan, por ejemplo, de forma sucesiva, sirviendo el
resultado de un workflow siempre como fuente del siguiente
Workflow.
Una instrucción PersonalizeOnTemplate
hace que se origine un nuevo archivo PDF en el que se encuentran
sucesivamente varias cartas que están compuestas por el modelo PDF
y están personalizadas con los conjuntos de datos a partir de los
datos variables. El número de cartas se ajusta según el atributo
AddressesPerPly. Para generar cartas para todos los datos
variables, puede mostrarse PersonalizeOnTemplate dentro de
Loop. Con esto se originan varios archivos PDF con un número
de cartas AddressesPerPly en cada caso. Si el número de
direcciones no es divisible de forma exacta entre
AdressesPerPly, en el último archivo PDF se encuentran las
cartas restantes. Si se encuentran diferentes UserJobs en el
PrintJob, se utiliza automáticamente el modelo PDF que se adapta a
la dirección correspondiente.
Para la clasificación de envíos postales se
fijan normalmente criterios Infopost que, por ejemplo, pueden
comprender Infobrief, Infopost o estándar. Si durante la
personalización se ajusta un criterio Infopost de este tipo, sólo se
tratan direcciones que poseen el criterio Infopost
correspondiente.
A continuación, se muestra un ejemplo de
esto:
\vskip1.000000\baselineskip
Mediante las instrucciones anteriores se
originan varios archivos PDF en Temppath con los nombres
new_ID_ x_Pers_y con el siguiente significado:
- X:
- Índice para detectar el paquete parcial. Va desde 0 hasta "InitialNumberOfPieces"/"AdressesPerPly" (redondeado).
- Y:
- El criterio Infopost correspondiente. 1: Infobrief, 2: Infopost; 3: estándar.
La suma de todas las cartas a partir de los
diferentes criterios Infopost con un valor para X es igual a
AddressePerPly o el resto de la división.
Además, resulta ventajosa una función
Personalize, que funciona como PersonalizeOnTemplate,
fuera de la cual no se personaliza en el modelo PDF, sino en un
nuevo documento vacío. Los atributos "Personalize" pueden
tener, por ejemplo, la siguiente forma:
Una función OpenPDF hace que se abra un
archivo PDF. Este archivo sirve en otras instrucciones como fuente.
Un atributo de OpenPDF es, por ejemplo, Filename:
Además, resulta ventajoso que con VariableData
puedan colocarse datos adicionales en un archivo PDF. En este caso
sirve como modelo el documento actual, que o bien se ha abierto
mediante OpenPDF, del que procede el actual Workflow, o se
origina finalmente dentro del Workflow actual. Para esto debe
indicarse un intervalo de páginas. En este intervalo de páginas se
ejecutan las instrucciones registradas dentro de
VariableData. Dentro de VariableData son posibles
"AddText", "AddSDL", "AddLine" y "AddOMR".
Atributos de VariableData son, por ejemplo:
Con funciones como StartPage y
EndPage también pueden realizarse indicaciones matemáticas.
Pueden admitirse, por ejemplo, los siguientes símbolos:
Además, Endpage="last/2+1" conduce,
por ejemplo, a que las páginas se traten hasta las páginas
centrales rectas.
Dentro de VariableData puede utilizarse
una función AddText para añadir un texto:
\vskip1.000000\baselineskip
\newpage
Una función AddLine puede utilizarse
dentro de VariableData para añadir una línea entre dos
puntos:
Una función AddOMR puede utilizarse
dentro de VariableData para añadir en páginas códigos de
control OMR:
En este caso para cada trazo de código de
control dentro de AddOMR debe añadirse una etiqueta
"Line".
Una función EmptyPageInsert añade, por
ejemplo, una o varias páginas vacías nuevas. Los siguientes son
posibles atributos:
\newpage
Mediante una función Merge pueden
agruparse diferentes archivos PDF:
Dentro de Merge los documentos que han de
añadirse se indican de forma conveniente con InsertPDF.
Pueden ser atributos de InsertPDF, por ejemplo, los
siguientes:
\vskip1.000000\baselineskip
Una función Impositioning es conveniente
para determinar cómo debe realizarse la imposición de un documento.
Dentro de Impositioning pueden describirse tantas páginas
como se desee. En la descripción de las páginas se determina qué
páginas del documento original se colocan sobre las nuevas páginas.
La descripción de las páginas se realiza preferiblemente varias
veces, calculándose nuevamente en cada caso la página original que
va a tomarse. El número de ciclos se ajusta según los valores en
Signature, Increment y según el número de páginas
originales. Preferiblemente, se realiza con una frecuencia adaptada
al número de páginas en Signatura*Increment (redondeado).
\newpage
Posibles atributos para Impositioning son
los siguientes:
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
Los siguientes son atributos para
AddPage:
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
Dentro de la configuración del medio de
generación de pedidos de impresión puede accederse a diferentes
variables. Estas variables pueden utilizarse para elaborar un
nombre de documento y diferentes textos en nuevos documentos. Las
variables se ajustan, dependiendo de la función, al inicio o
durante la producción.
Para el mantenimiento local de los datos dentro
del sistema 10 de impresión según la invención con un medio 15 de
generación de pedidos de impresión instalado resulta ventajoso un
QueueManager. Éste gestiona las informaciones necesarias para todos
los UserJobs y Printjobs, tales como, por ejemplo, estado, archivos
y/o atributos. Para esto el QueueManager utiliza preferiblemente
una estructura jerárquica de datos. Esta estructura de datos la
deposita con cada cambio en un medio de almacenamiento, tal como un
disco duro, para que tras un nuevo inicio del sistema siga estando
presente toda la información. El directorio puede configurarse, por
ejemplo, mediante un atributo QueueManagerPath en un archivo
de configuración (PSSConfiguration.xml). En el directorio, el
QueueManager registra en cada caso un directorio para UserJobs y
Printjobs en los que se almacenan los archivos XNIL
correspondientes.
\newpage
A continuación, se muestra un ejemplo de
QueueManager. El contenedor más exterior se denomina siempre
QueueManager. En este se encuentran dos contenedores: PrintJobs,
para todos los PrintJobs, y UserJobs, para todos los UserJobs.
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
Una estructura de datos a modo de ejemplo que
registra el QueueManager para un UserJob puede desprenderse de la
siguiente tabla:
\vskip1.000000\baselineskip
\newpage
Durante la sincronización con el servidor SOAP
se consultan los atributos de nuevos UserJobs. Con estos atributos,
el QueueManager registra un nuevo UserJob. En este caso se procede,
por ejemplo, de la siguiente manera:
- -
- creación del nuevo contenedor de UserJob
- -
- se establece el ID de atributo con UserJobID
- -
- se ajusta el atributo Status a READY_FOR_DOWNLOAD
- -
- el atributo Percentage se ajusta a 0
- -
- LogicalProduct se ajusta al valor correspondiente
- -
- Downloaded se ajusta a FALSE
- -
- LastChangeDate se ajusta a la hora actual
- -
- se añade el contenedor UserAttribute
- -
- se añade un contenedor de PrintJobs vacío
- -
- AddressCount se ajusta a partir de las informaciones de UserJob
- -
- CreationDate se ajusta a partir de la información de Job
- -
- PageCountLetter se ajusta a partir de la información de Job
- -
- PageCountSum se ajusta a partir de la información de Job
- -
- Se añade el contendor AvailablePrinter.
De la configuración en una PSSConfiguration se
desprenden posibles impresoras virtuales. Se añaden todas las
impresoras cuyas PrintJobsConditions no descarten ninguno de
los atributos del UserJob. Las PrintJobConditions se
almacenan para cada impresora en la estructura. Si más adelante se
generan uno o varios PrintJobs a partir del UserJob, se incluyen
los correspondientes UserJobID en el contenedor PrintJobs.
Con cada cambio, por ejemplo, en caso de cambios de estado, el
QueueManager ajusta de nuevo el atributo LastChangeDate. Si
se descarga el UserJob, entonces se ajusta DownladedDate y
el archivo XML descargado se almacena en el directorio UserJob.
De la siguiente tabla puede desprenderse una
estructura de datos a modo de ejemplo que el QueueManager registra
para un PrintJob:
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
Si se registra un PrintJob a partir de uno o
varios UserJobs, el QueueManager genera el contenedor PrintJob
correspondiente. En este caso se procede, por ejemplo de la
siguiente manera:
- -
- A partir del archivo XML UserJob se genera uno o varios archivos XML PrintJob
- -
- Se coloca el contendor de PrintJob
- -
- Se ajusta el estado a WAITING
- -
- Se ajusta LogicalProduct, estando predeterminado el valor mediante el/los UserJob(s)
- -
- Se registra el contendor de UserJob y se registran todos los UserJobs de los que se compone este PrintJob
- -
- Se copia y añade el contenedor AvailablePrinter del UserJob
- -
- Si a partir de un UserJob deben generarse varios PrintJobs, se ajusta StartAddress y EndAddress (el intervalo de dirección para este PrintJob)
- -
- Se ajusta PageCountSum (número de todas las páginas de impresión en este PrintJob)
- -
- Se ajusta CurrentPrinter a la impresora seleccionada
- -
- Se determina en cuántos Plys debe dividirse el PrintJob (Se desprende de las cartas que han de imprimirse y los atributos AddressPerPly de la impresora en la configuración)
- -
- Se elabora de forma correspondiente el contenedor Plys y se ajustan todos los Plys a WAITING
- -
- Se ajusta CreationDate a la hora actual.
Con cualquier cambio adicional del
PrintJob-Status, se ajusta LastChangeDate y
Percentage de los UserJobs correspondientes.
Al generar un PrintJob, se genera un nuevo
archivo XML PrintJob a partir de los archivos XML UserJob. Esta
función la sume, por ejemplo, una clase RecreateXML. El archivo XML
UserJob contiene, por ejemplo,
User-Job-Attribute,
Company-Daten, Item-Daten y
UserJob-Files. Los UserJob Files están codificados
en base64 en un ejemplo especialmente preferido de la invención.
Base64 es una codificación que se utiliza mediante el programa
MIMENCODE en el estándar MIME para transformar archivos binarios en
un subconjunto ASCIT.
La clase RecreateXML agrupa todos los
UserJobs en un JOBTRANSFER-ENVELOPE. El
UserJob-Attribute, Company-Daten e
Item-Daten de cada UserJob se aceptan sin
modificar. RecreateXML modifica los archivos con las
instrucciones Print y los datos variables. El resto de los archivos
se aceptan.
Si un UserJob está dividido en varios PrintJobs,
los datos variables se dividen en conjuntos. Cada PrintJob contiene
uno de estos grupos.
Las instrucciones Print de los UserJobs pueden
estar, por ejemplo, en el siguiente formato:
\vskip1.000000\baselineskip
RecreateXML utiliza preferiblemente un
formateador de direcciones para generar a partir de esto
instrucciones de impresión que puede comprender el kernel PDF. En el
PrintJob-File, las instrucciones Print para el
archivo anteriormente indicado tienen, por ejemplo, la siguiente
forma:
En el archivo XML, los datos variables tienen,
por ejemplo, la siguiente forma:
\vskip1.000000\baselineskip
\newpage
Utilizando la asociación en el archivo
Print-Instruct, RecreateXML genera a partir
de esto lo siguiente:
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
Con esto, en la personalización durante la
producción se facilitan los datos en la forma que el kernel PDF
puede utilizar directamente.
El QueueManger gestiona el estado para todos los
UserJobs, PrintJobs y Plys. Un modelo de datos de una interfaz
informa al QueueManager de cambios de estado. En este caso pueden
presentarse, por ejemplo, los siguientes estados:
\vskip1.000000\baselineskip
\newpage
Además, se ha mostrado conveniente que el
QueueManager, en caso de cambios de estado de UserJobs y PrintJobs,
ajuste un atributo Percentage para los UserJobs. Este
atributo indica el grado de preparación del UserJob en porcentaje.
Durante la sincronización con el servidor 20 se transmite este valor
para cada UserJob. En la siguiente tabla se muestra el estado de
UserJob y PrintJob en conexión con el porcentaje de
preparación:
\vskip1.000000\baselineskip
Resulta especialmente ventajoso que usuarios del
medio 15 de generación de pedidos de impresión según la invención
puedan supervisar y controlar la producción dentro de un sistema 10
de impresión mediante una interfaz de usuario. La interfaz puede
implementarse, por ejemplo, empleando Java Swing. En este caso, los
datos para la interfaz los gestiona, por ejemplo, una clase
DataModel (modelo de datos) que realiza consultas al
QueueManager para determinar valores.
Además, resulta ventajoso que un usuario pueda
darse de alta y de baja en el servidor SOAP y finalizar el programa
a través de un menú. Estas funciones están disponibles
preferiblemente en una barra de herramientas. Durante el alta,
puede abrirse, por ejemplo, un cuadro de diálogo en el que han de
indicarse el nombre de usuario y la contraseña. Con estos datos, el
sistema intenta darse de alta en el servidor SOAP mediante un
método authenticateUser del servidor proxy. Si la solicitud
es válida, se almacenan las informaciones del usuario en el modelo
de datos. Estas informaciones de usuario se utilizan en la
comunicación posterior con el servidor. En caso de no ser válidas,
aparece de forma conveniente un cuadro de diálogo con un mensaje de
fallo.
En este caso, resulta ventajoso implementar una
función "dar de baja" que borre información de usuario del
modelo de datos, de modo que ya no sea posible la comunicación con
el servidor sin una nueva solicitud. Otra función "dar de baja y
finalizar" comprueba si aún se están ejecutando transacciones de
producción. Si aún existen transacciones, se realiza otra consulta
para determinar si debe finalizarse el programa. El programa se
finaliza, por ejemplo, con System.exit(0).
Mediante un cuadro de diálogo combinado pueden
generarse, por ejemplo, tres vistas diferentes en los UserJobs.
Para todas las vistas hay clases modelo interiores en la clase
Marco principal (AplicaciónMrc). El marco principal inicializa
varios ChangeListener que en caso de un cambio de la selección
UserJob y un cambio de UserJob-Status ajustan las
acciones posibles. Las acciones posibles las consulta el modelo de
datos. El modelo de datos deduce las acciones posibles del estado
de los UserJobs seleccionados que el QueueManager consulta.
Mediante el menú UserJob pueden descargarse
UserJobs, transformarse para formar PrintJobs, cancelarse,
ajustarse a no producible, cancelarse y producirse con un
asistente. Todas las acciones pueden activarse también mediante una
barra de herramientas. Las acciones posibles dependen del estado de
los UserJobs seleccionados.
\newpage
En la siguiente tabla se muestran las
asociaciones entre estado de UserJob y posible acción:
En la siguiente tabla se muestran las
repercusiones de las acciones UserJob:
Además, resulta especialmente ventajoso el
empleo de un asistente de producción. El asistente de producción
agrupa todos los UserJobs seleccionados según productos. En caso de
que no se haya seleccionado ningún UserJob, se utilizan todos los
UserJobs. Para la agrupación, el asistente utiliza, por ejemplo,
los atributos PRINT_MODE,
PRINT_COLOR y PRINT_FORMAT.
PRINT_COLOR y PRINT_FORMAT.
La siguiente tabla muestra los productos del
asistente y sus atributos:
La vista sobre los PrintJobs también puede
hacerse seleccionable mediante un cuadro de diálogo combinado. Las
vistas y el manejo de las acciones está realizados como en los
UserJobs, con la diferencia de que el QueueManager consulta los
valores para Printjobs.
Las posibles acciones dependen del estado de los
PrintJobs seleccionados. En la siguiente tabla se muestra la
asociación entre estado de PrintJob y posible acción:
La siguiente tabla muestra las repercusiones de
las acciones PrintJob:
Una forma de realización ventajosa de la
invención es, además, que un usuario pueda sincronizar mediante un
menú Servidor y reiniciar la memoria caché local.
Si se realiza una sincronización, el medio de
generación de pedidos de impresión envía primero al servidor todos
los estados y el grado de preparación en porcentaje de los UserJobs
locales empleando el servidor proxy. Si un UserJob tiene el estado
CANCELED, FAILED o DELIVERED, se le indica a continuación al
QueueManager que elimine localmente estos Jobs. Tras la transmisión
del estado, el medio de generación de pedidos de impresión consulta
todos los UserJobs "exportables" descargables. En caso de que
aún no esté presente localmente un UserJob descargable, se solicita
al QueueManager que lo registre. Después, el servidor consulta los
atributos de este nuevo UserJob y lo comunica al QueueManager. En
caso de que durante la consulta de los atributos se produzca un
fallo, se solicita al QueueManager que ajuste este UserJob a
NOTPRODUCEABLE.
En la siguiente etapa, el medio de generación de
pedidos de impresión consulta la lista de los UserJobs ya
descargados del servidor SOAP. En caso de que ya no estén presentes
localmente UserJobs que ya se han descargado, el QueueManager
registra nuevamente los UserJobs y se descargan. Esto puede
producirse, por ejemplo, si se borran los archivos locales del
QueueManager. En caso de que haya UserJobs locales que no estén en
la lista de los UserJobs descargados, estos UserJobs se eliminan
localmente.
Si se reinicia la caché local, se activan
primero todos los PrintJobs. Después se borran todos los archivos
que gestiona el QueueManager. Tras el siguiente reinicio del
QueueManager, se realiza una sincronización en la que, no obstante,
se suprime la transmisión del estado al servidor SOAP.
En un ejemplo de realización especialmente
preferido de la invención, se indican al usuario en un cuadro de
diálogo todos los fallos que se presentan dentro del medio de
generación de pedidos de impresión. Además, los fallos se almacenan
con la fecha en un archivo de registro. El archivo se llama, por
ejemplo, Error.log y se dispone en un directorio que se indica en
la configuración en errorpath.
Preferiblemente, todas las informaciones
utilizadas para la producción están almacenadas en un
JobEnvironment. En este caso, primero todos los UserJobs contenidos
en el PrintJob se almacenan en objetos de datos de una clase
UserJobData. Estos objetos de datos ofrecen un acceso a todos
los datos UserJob importantes para la producción. Para que se
conozca el número total, se suma y almacena el número de
direcciones, páginas y hojas de todos los UserJobs.
JobEnvironment analiza cuántas cartas están
previstas para un criterio Infopost correspondiente Infobrief,
Infopost o estándar. A partir de cada dirección se genera un objeto
de datos de una clase Letter. Para el desarrollo adicional de la
producción JobEnvironment facilita métodos para consultar
determinada información mediante los UserJob.
La clase Letter contiene información para una
carta. A ésta pertenecen, por ejemplo, informaciones de
personalización, número de páginas de la carta, el criterio
Infopost, el UserJoblD y la posición dentro del UserJob. El
JobEnvironment gestiona una lista con objetos Letter para toda la
carta.
Preferiblemente, un objeto de la clase
UserJobData contiene todos los datos de un UserJob. A éstos
pertenecen todos los atributos UserJob, informaciones de puerto,
precio y empresa. El JobEnvironment tiene una lista de UserJobs con
todos los objetos UserJobData del Job. La clase UserJobData ofrece
métodos para acceder a las informaciones UserJob.
Para gestionar el contenido de las páginas PDF
es conveniente el uso de una clase PageContent. Objetos de esta
clase describen para una página qué cartas se encuentran en la
página en qué posición. Es posible que en una página, tras realizar
el Impositioning, se encuentren varias cartas.
Preferiblemente, con ayuda de una tabla Hash
DocumentContent se gestiona el contenido de página para cada
archivo PDF. Allí se almacena para cada documento PDF el nombre de
archivo y una lista de PageContent. Éstos se elaboran
preferiblemente por una capa PDF. Las informaciones sirven para una
elaboración SDL y OMR y para crear un modelo PDF con contenido
estático.
Además, resulta ventajoso generar para un
archivo PDF existente con datos de personalización en un punto
cualquiera un modelo PDF con los contenidos estáticos. En este caso
se examina qué páginas del modelo son necesarias. En
VariableToTemplateMatch se determina qué página personalizada
pertenece a una página estática. La información se necesita
eventualmente en caso de una generación posterior de un
Book-Ticket. En varToTemplateMatchArray se
registran para cada ciclo Loop la
variableToTemplateMatch.
Después de que se haya ajustado el
JobEnvironment, el kernel PDF elabora los archivos imprimibles
mediante la impresora virtual que está en la configuración. Para
esto, en una forma de realización especialmente preferida de la
invención, el kernel tiene varios niveles. En el nivel superior
(JobHandler) se selecciona la impresora virtual, se lee el PrintJob
y se inicializa el JobEnvironment. Después, el JobHandler procesa
gradualmente las entradas PrepareDocumentStep de la
impresora virtual. En este nivel, se identifican las entradas
NewPDF, Loop, Workflow, Personalize, CreateTemplatePDF,
PersonalizeOnTemplate, Repeat y OpenPDF, y, en función de la
palabra clave, se llama un método del siguiente nivel. En el
siguiente nivel (DocumentHandler) se valoran las instrucciones que
se disponen dentro de las entradas anteriormente citadas. Las
entradas que se disponen en estas entradas se valoran por otro nivel
(PDFDocument). PDFDocument utiliza PDFLayer para abrir y elaborar
los documentos.
Para elaborar y leer los documentos PDF, en un
ejemplo de realización especialmente preferido de la invención se
ha incorporado una biblioteca PDFLib externa. Esta
biblioteca permite una elaboración sencilla de documentos PDF
mediante llamadas de función. Las páginas PDF existentes también
pueden añadirse en nuevos documentos PDF. Los accesos a esta
biblioteca se realizan todos preferiblemente por una
PDFAccessLayer. Con esto, el código restante es independientemente
de la biblioteca y, en caso de un cambio eventual a otra
biblioteca, sólo debe adaptarse la capa.
La capa también es responsable del ajuste de
DocumentsContent en JobEnvironment. Cada vez que se
registra un archivo PDF existente, se genera un PageContent
vacío y se comunica el nombre de archivo al JobEnvironment. Durante
la personalización, se comunica a PDFlayer qué página de la carta se
coloca. PDFLayer genera un PageContent correspondiente y lo
proporciona a JobEnvironment. Cada vez que se abre un archivo
existente, PDFLayer toma de JobEnvironment los contenidos de página
(PageContent). Si este documento copia una página en un nuevo
documento, PDFLayer calcula la posición en la nueva página y genera
con ello un PageContent.
Para la conversión de los archivos PDF según
Postscript, se ha mostrado conveniente utilizar una DLL pdf2ps_java
en C. Esta DLL puede solicitar, por ejemplo, el programa Adobe
Acrobat y Acrobat Reader. La DLL abre el programa y le indica que
transforme un archivo PDF según Postscript. La DLL se carga por la
clase Pdf2PsNativeInterface. La clase Pdf2PsConverter
utiliza Pdf2PsNativeInterface y facilita un método de
conversión.
- 10
- Sistema de impresión
- 11
- Impresora
- 12
- Instalación de clasificación
- 13
- Instalación de ensobrado
- 14
- Componente de tratamiento de la impresión
- 15
- Medio de generación de pedidos de impresión
- 16
- Primer mensaje
- 17
- Segundo mensaje
- 18
- Clase Call
- 20
- Servidor
- 21
- Servidor Web
- 22
- Servidor proxy
- 30
- Base de datos
- 40
- Primera interfaz
- 50
- Segunda interfaz
- 60
- Internet.
Claims (4)
1. Sistema para la generación automática de
archivos imprimibles a partir de datos de una base (30) de datos,
comprendiendo dicho sistema un sistema (10) de impresión que está
compuesto por al menos un componente (14) de tratamiento de la
impresión, presentando el componente (14) de tratamiento de la
impresión medios para imprimir y/o tratar adicionalmente los
archivos imprimibles, caracterizado por las siguientes
características:
- el sistema (10) de impresión presenta al menos
un medio (15) de generación de pedidos de impresión, siendo el
medio de generación de pedidos de impresión un programa en al menos
un ordenador del sistema (10) de impresión,
- el medio (15) de generación de pedidos de
impresión puede conectarse con un servidor (20) a través de
Internet y una primera interfaz (40), siendo la primera interfaz
(40) una interfaz SOAP (Simple Object Access Protocol, protocolo
simple de acceso a objetos) y el servidor (20), un servidor SOAP, y
la interfaz SOAP utiliza http/HTTPS como protocolo de transmisión
de datos,
- el servidor (20) puede conectarse con una base
(30) de datos mediante una segunda interfaz (50), encontrándose la
base (30) de datos por fuera del área del sistema (10) de impresión
y la segunda interfaz (50) es una capa PL/SQL (Procedural Language
/ Structured Query Language, lenguaje procesal / lenguaje
estructurado de consulta),
- el medio (15) de generación de pedidos de
impresión presenta medios para la solicitud y recepción de datos
procedentes de la base (30) de datos, y
- el medio (15) de generación de pedidos de
impresión presenta medios para preparar los datos de la base (30)
de datos para los requerimientos del componente (14) de tratamiento
de la impresión y medios para generar archivos imprimibles.
2. Procedimiento para la generación automatizada
de archivos imprimibles a partir de datos de una base (30) de
datos, en el que los archivos se generan, imprimen y/o tratan
adicionalmente mediante un sistema (10) de impresión que está
compuesto por al menos un componente (14) de tratamiento de la
impresión y un medio (15) de generación de pedidos de impresión,
caracterizado por las siguientes etapas:
- el medio (15) de generación de pedidos de
impresión genera un primer mensaje (16) que incluye una llamada a un
servidor (20) para un determinado método con parámetros,
- el medio (15) de generación de pedidos de
impresión establece mediante Internet y una primera interfaz (40)
una conexión con el servidor (20), siendo el servidor (20) un
servidor SOAP,
- el medio (15) de generación de pedidos de
impresión transmite al servidor (20) el primer mensaje (16) a
través de la primera interfaz (40), realizándose la comunicación
entre el medio (15) de generación de pedidos de impresión y el
servidor (20) mediante una interfaz SOAP,
- el servidor (20) trata el primer mensaje (16)
solicitando el método determinado con los parámetros
correspondientes,
- el servidor (20) establece una conexión con la
base (30) de datos a través de una segunda interfaz (50),
realizándose la comunicación entre el servidor (20) y la base (30)
de datos a través de una capa PUSQL (Procedural Language /
Structured Query Language),
Structured Query Language),
- el servidor (20) solicita datos de la base
(30) de datos a través de la segunda interfaz (50),
- el servidor devuelve el resultado de la
solicitud del método determinado en forma de un segundo mensaje
(17) al medio (15) de generación de pedidos de impresión, y
- el medio (15) de generación de pedidos de
impresión genera a partir del resultado de la solicitud del método
determinado al menos un archivo imprimible.
3. Procedimiento según la reivindicación 2,
caracterizado porque la comunicación entre el medio (15) de
generación de archivos de impresión y el servidor (20) se realiza a
través de una interfaz Apache SOAP-API.
4. Procedimiento según una o las dos
reivindicaciones 2 y 3, caracterizado por las siguientes
etapas:
- el medio (15) de generación de pedidos de
impresión genera un primer mensaje (16) en el que solicita una
instancia de una clase (18) Call de una interfaz Apache SOAP API y
ajusta propiedades de este objeto,
- el medio (15) de generación de pedidos de
impresión transfiere al servidor (20) el primer mensaje (16),
- en el lado del servidor (20), un servidor (21)
Web acepta el primer mensaje (16) con la llamada y lo valora,
- el URL enviado se asocia a un servlet
rpcrouter de la interfaz Apache SOAP-API en el que
se conoce el objeto Servidor SOAP,
- se transmite la llamada a este servlet,
- el servlet rperouter analiza el primer mensaje
SOAP (16), determina la clase que va a llamarse y la
particulariza,
- el método deseado se solicita con los
parámetros transferidos,
- el valor devuelto se transforma en un segundo
mensaje (17) SOAP y se devuelve como respuesta por http,
- la instancia de la clase (18) Call en el lado
del cliente analiza el segundo mensaje (17) y devuelve el resultado
generado al medio (15) de generación de pedidos de impresión.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| DE10254055A DE10254055B4 (de) | 2002-11-19 | 2002-11-19 | System und Verfahren zur automatisierten Erzeugung von druckbaren Dateien aus Daten |
| DE10254055 | 2002-11-19 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2289347T3 true ES2289347T3 (es) | 2008-02-01 |
Family
ID=32318561
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES03785519T Expired - Lifetime ES2289347T3 (es) | 2002-11-19 | 2003-11-14 | Sistema y procedimiento para la generacion automatizada de archivos imprimibles a partir de datos. |
Country Status (9)
| Country | Link |
|---|---|
| US (1) | US20060153616A1 (es) |
| EP (1) | EP1565810B1 (es) |
| AT (1) | ATE365943T1 (es) |
| AU (1) | AU2003294627A1 (es) |
| DE (2) | DE10254055B4 (es) |
| ES (1) | ES2289347T3 (es) |
| HR (1) | HRP20050548B1 (es) |
| PL (1) | PL375892A1 (es) |
| WO (1) | WO2004046907A1 (es) |
Families Citing this family (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2005339520A (ja) * | 2004-04-26 | 2005-12-08 | Ricoh Co Ltd | サービス提供装置、サービス提供プログラム、記録媒体及びサービス提供方法 |
| US8587798B2 (en) * | 2004-07-30 | 2013-11-19 | Hewlett-Packard Development Company, L.P. | Replacement component for a printing device |
| JP2007018346A (ja) * | 2005-07-08 | 2007-01-25 | Konica Minolta Business Technologies Inc | 処理装置およびその制御方法ならびにコンピュータプログラム |
| DE102005045816B4 (de) * | 2005-09-24 | 2007-12-06 | Safe Id Solutions Ag | Verfahren, Softwareprogrammprodukt und Vorrichtung zur Herstellung von Sicherheitsdokumenten |
| KR100823265B1 (ko) * | 2006-04-13 | 2008-04-17 | 삼성전자주식회사 | 모바일 디바이스에서 ＸＨＴＭＬ－Ｐｒｉｎｔ 문서를전송하는 방법 및 장치 |
| US9734442B2 (en) * | 2007-10-31 | 2017-08-15 | Ncr Corporation | LumID barcode format |
| JP2010039938A (ja) * | 2008-08-07 | 2010-02-18 | Fuji Xerox Co Ltd | 文書処理装置及び文書処理プログラム |
| US8805095B2 (en) | 2010-12-03 | 2014-08-12 | International Business Machines Corporation | Analysing character strings |
| US8595322B2 (en) * | 2011-09-12 | 2013-11-26 | Microsoft Corporation | Target subscription for a notification distribution system |
| US8694462B2 (en) | 2011-09-12 | 2014-04-08 | Microsoft Corporation | Scale-out system to acquire event data |
| US9208476B2 (en) | 2011-09-12 | 2015-12-08 | Microsoft Technology Licensing, Llc | Counting and resetting broadcast system badge counters |
| CN111384691B (zh) * | 2015-03-16 | 2021-08-27 | 康普技术有限责任公司 | 用于电缆分布组件的外壳 |
| US9830603B2 (en) | 2015-03-20 | 2017-11-28 | Microsoft Technology Licensing, Llc | Digital identity and authorization for machines with replaceable parts |
| JP6933020B2 (ja) * | 2016-09-29 | 2021-09-08 | 株式会社リコー | 画像処理装置、情報処理システム、および方法 |
| CN113791743B (zh) * | 2021-08-09 | 2024-07-09 | 西安立人行档案文件管理咨询有限公司 | 一种基于http协议的打印控制方法、装置及介质 |
| US11715317B1 (en) | 2021-12-27 | 2023-08-01 | Konica Minolta Business Solutions U.S.A., Inc. | Automatic generation of training data for hand-printed text recognition |
Family Cites Families (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE19849962A1 (de) * | 1998-02-25 | 1999-09-09 | Hewlett Packard Co | Vorrichtung und Verfahren zum Aufteilen eines Druckauftrags unter mehreren Druckern |
| DE19817878A1 (de) * | 1998-04-22 | 1999-11-04 | Juerg Paul Haller | Verfahren zur Herstellung von Drucksendungen, Einrichtung zur Herstellung von Drucksendungen, Umhüllung für eine nach dem Verfahren hergestellte Drucksendung sowie ein zur Verwendung bei einem solchen Verfahren hergestelltes Kuvert |
| JP2000025305A (ja) * | 1998-07-08 | 2000-01-25 | Seiko Epson Corp | 通信装置付きプリンタ |
| TW487879B (en) * | 2000-02-16 | 2002-05-21 | Hotpaper Com Inc | Internet document creation system and document-format generator therefor |
| DE10017785C2 (de) * | 2000-04-10 | 2002-04-18 | Oce Printing Systems Gmbh | Verfahren und System zur Verarbeitung eines Druckdatenstroms |
| US6509974B1 (en) * | 2000-05-17 | 2003-01-21 | Heidelberger Druckmaschinen Ag | Automated job creation for job preparation |
| JP2004523022A (ja) * | 2000-09-07 | 2004-07-29 | ユナイテッド ステイツ ポスタル サービス | 郵送オンラインオペレーションフロー |
| US7136486B2 (en) * | 2000-09-11 | 2006-11-14 | Seiko Epson Corporation | Print system and printer capable of prevention of unjust copy print |
| DE10211339B4 (de) * | 2001-04-02 | 2004-09-16 | Hewlett-Packard Co. (N.D.Ges.D.Staates Delaware), Palo Alto | Verfahren zum Akualisieren von Software in einem Drucksystem |
| US6996574B2 (en) * | 2001-04-18 | 2006-02-07 | Csg Systems, Inc. | System and method for accessing database design information |
| US20030069801A1 (en) * | 2001-10-04 | 2003-04-10 | Che-Mponda Aleck H. | System and method of transmitting and accessing digital images over a communication network |
| US20030169446A1 (en) * | 2002-03-07 | 2003-09-11 | Grohs Randall Edward | System and method for proxy management of a print job |
-
2002
- 2002-11-19 DE DE10254055A patent/DE10254055B4/de not_active Expired - Fee Related
-
2003
- 2003-11-14 DE DE50307584T patent/DE50307584D1/de not_active Expired - Lifetime
- 2003-11-14 ES ES03785519T patent/ES2289347T3/es not_active Expired - Lifetime
- 2003-11-14 PL PL03375892A patent/PL375892A1/xx unknown
- 2003-11-14 WO PCT/DE2003/003789 patent/WO2004046907A1/de not_active Ceased
- 2003-11-14 US US10/535,506 patent/US20060153616A1/en not_active Abandoned
- 2003-11-14 HR HR20050548A patent/HRP20050548B1/xx not_active IP Right Cessation
- 2003-11-14 AT AT03785519T patent/ATE365943T1/de not_active IP Right Cessation
- 2003-11-14 AU AU2003294627A patent/AU2003294627A1/en not_active Abandoned
- 2003-11-14 EP EP03785519A patent/EP1565810B1/de not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| ATE365943T1 (de) | 2007-07-15 |
| WO2004046907A1 (de) | 2004-06-03 |
| PL375892A1 (en) | 2005-12-12 |
| AU2003294627A1 (en) | 2004-06-15 |
| DE50307584D1 (de) | 2007-08-09 |
| US20060153616A1 (en) | 2006-07-13 |
| EP1565810B1 (de) | 2007-06-27 |
| DE10254055B4 (de) | 2006-10-26 |
| HRP20050548B1 (hr) | 2008-01-31 |
| DE10254055A1 (de) | 2004-06-17 |
| HRP20050548A2 (en) | 2005-08-31 |
| EP1565810A1 (de) | 2005-08-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2289347T3 (es) | Sistema y procedimiento para la generacion automatizada de archivos imprimibles a partir de datos. | |
| US8024233B2 (en) | System and method for processing personalized stationery designs and selecting fulfillment order sites | |
| CN1605081B (zh) | Xml打印机系统 | |
| US10148656B2 (en) | Securing shipment information accessed based on data encoded in machine-readable data blocks | |
| US9201845B2 (en) | XML printer system | |
| US7407102B2 (en) | XML printer system | |
| EP2216744A2 (en) | System and method for providing an extensible multinational postage service and system and method that delivers printable postage to a client device | |
| US20080005144A1 (en) | Apparatus and method for transferring data between incompatible computer systems | |
| US20100076585A1 (en) | Method for the production of a label, and device for carrying out said method | |
| JP2005529411A5 (es) | ||
| JP2005529411A (ja) | ルールに基づく内容の検証を用いた包装データの集中管理 | |
| ES2445826T3 (es) | Método para generar sobres de envío postal bajo demanda | |
| US20080030771A1 (en) | Xml printer system | |
| US20030097306A1 (en) | Shipping system and method utilizing an application programming interface for faciltating transfer of information related to shipping of packages | |
| EP1279105A1 (en) | Method and system for preparing printed matter | |
| US20050137937A1 (en) | Method and apparatus for web-based label printing | |
| US20030110223A1 (en) | System and method for correcting the failed delivery of electronic documents | |
| US7333223B2 (en) | System and method for electronically delivering documents | |
| KR20000049816A (ko) | 인터넷을 이용한 인쇄물 제작 및 배달 방법 | |
| JP2000242718A (ja) | 商品配送システム、配送センタ、受付端末及び記録媒体 | |
| WO2002041166A1 (en) | Personalized greeting card system for retailers | |
| JP2004357058A (ja) | 電子的文書認証処理システム | |
| IES20070117A2 (en) | A book manufacturing system | |
| JP2002298069A (ja) | 二次元シンボルとイメージ処理による手書帳票入力方法およびプログラム | |
| WO2007096851A1 (en) | A book manufacturing system |