Elementos xJCL

Los trabajos se expresan en un dialecto de XML (Extensible Markup Language) denominado xJCL (Lenguaje de control de trabajos XML). Este dialecto tiene construcciones para expresar toda la información necesaria para los trabajos por lotes o los trabajos con una actividad de proceso intensiva, aunque algunos elementos de xJCL sólo son aplicables a los trabajos por lotes o los trabajos con una actividad de proceso intensiva. Consulte el xJCL que se proporciona con las aplicaciones de ejemplo, la tabla xJCL y el documento de esquema XSD de xJCL para obtener más información sobre xJCL. La definición xJCL de un trabajo no forma parte de la aplicación de proceso por lotes, pero se construye y somete aparte del planificador de trabajos a ejecutar. El planificador de trabajos utiliza la información de xJCL para determinar dónde y cuándo se debe ejecutar el trabajo.

Elementos xJCL

La tabla siguiente resume los elementos xJCL.

Tabla 1. Elementos xJCL. La tabla incluye los elementos xJCL, ya sea que cada elemento xJCL se aplique a trabajos de proceso intensivo o de proceso por lotes de Java™ Platform, Enterprise Edition (Java EE) y los subelementos, atributos y descripciones de cada elemento xJCL.
Elemento Proceso intensivo de Java EE Proceso por lotes de Java EE Subelemento Atributos Descripción
job     Ámbito de la descripción de un trabajo por lotes.
job   nombre Nombre del trabajo. Este nombre debe coincidir con el nombre de la aplicación de proceso por lotes a menos que esté especificado nombre_aplicación_predeterminado.
job   accounting Atributo de información de cuenta opcional.
job   class Atributo de clase de trabajo opcional, que identifica la clase de trabajo bajo la que se ejecuta el trabajo.
job   default-application-name El nombre de aplicación que se va a utilizar cuando no se encuentre ningún atributo application-name de paso de trabajo.

Nombre de aplicación que debe utilizarse. Para las aplicaciones por lotes OSGi, el formato del nombre debe ser osgi:< >nombre eba:<versión>.

job jndi-name   Nombre JNDI que se asigna al bean de sesión sin estado del controlador de trabajos cuando la aplicación de proceso por lotes se despliega en el producto.
job job-scheduling criteria required-capability La capacidad necesaria del trabajo, que debe definirse en un punto final para que se entregue el trabajo a ese punto final.
job step-scheduling criteria Consulte el elemento step-scheduling-criteria  
job no checkpoint algorithm Consulte el elemento checkpoint-algorithm  
job no results-algorithm Consulte el elemento de algoritmos de resultados  
job substitution-props++ Consulte el elemento prop La capacidad necesaria del trabajo, que debe definirse en un punto final para que se entregue el trabajo a ese punto final
job-step sí*   nombre Nombre del paso opcional. Esta información se devuelve en los mandatos operativos.
job-step sí*   application-name Nombre opcional de la aplicación que ejecuta el paso. Se utiliza el nombre de atributo si se omite application-name y se omite el atributo de nivel de trabajo default-application-name.
job-step no step-scheduling Consulte el elemento step-scheduling Permite la lógica condicional basada en códigos de devolución de pasos que determinan si se invoca el paso por lotes.
job-step classname   Nombre plenamente cualificado de la clase que implementa el trabajo con una actividad de proceso intensiva.
job-step no checkpoint-algorithm-ref   Especifica el algoritmo de punto de control que se va a utilizar para el paso de trabajo por lotes.
job-step no results-ref Consulte el elemento results-ref Especifica el algoritmo de resultados que se va a utilizar para la ejecución condicional del paso de trabajo por lotes.
job-step no batch-data-streams Consulte el elemento batch-data-streams Secuencia de elementos bds. Cada bds contiene la información de configuración necesaria para crear una secuencia de datos por lotes.
job-step props Consulte el elemento props Propiedades nombre-valor que se van a pasar al paso.
job-step no no exec Consulte el elemento exec Identifica el ejecutable asociado al paso de trabajo.
job-step no no env-entries Consulte el elemento env-entries Identifica las propiedades de entorno asociadas al paso de trabajo.
prop     Instancia única de un par de nombre y valor que sirve de propiedad.
prop   nombre Nombre de la propiedad.
prop   value Valor de la propiedad.
props prop Consulte el elemento prop  
env-entries no no     Serie de elementos prop que se utilizan para pasar propiedades de pares de nombre y valor a los pasos, bds, algoritmos de punto de control y algoritmos de resultados.
env-entries no no env-var Consulte el elemento env-var  
exec no no     Serie de elementos prop que se utilizan para pasar propiedades de pares de nombre y valor a los pasos, bds, algoritmos de punto de control y algoritmos de resultados.
exec no no   executable Nombre del ejecutable asociado al paso de trabajo.
exec no no arg Consulte el elemento line  
line no no     Los argumentos de línea de mandatos pasados al ejecutable del paso de trabajo.
bds no     Instancia única de implementación de una secuencia de datos por lotes a la que puede acceder el trabajo por lotes.
bds no logical-name   Serie incorporada en el paso por lotes, que la utiliza para consultar al entorno de tiempo de ejecución por lotes una instancia específica de secuencia de datos por lotes.
bds no impl-class   Nombre de clase plenamente cualificado de la clase de implementación de la secuencia de datos por lotes.
bds no props Consulte los elementos props Lista de propiedades que se pasan a la clase de implementación de la secuencia de datos por lotes.
batch-data-streams no     Serie de elementos bds
batch-data-streams no bds Consulte el elemento bds  
step-scheduling no     Se aplica a los pasos de trabajo para crear flujos condicionales basados en el código de retorno para un trabajo por lotes. Compara los valores de códigos de retorno definidos para este trabajo por lotes para determinar si un paso se invoca o no durante el proceso de un trabajo por lotes. Los valores de códigos de retorno se comparan utilizando el elemento returncode-expression.
step-scheduling no returncode- expression Consulte el elemento returncode-expression Expresión Returncode- a evaluar.
step-scheduling no   condition Si hay más de un elemento returncode-expression en el elemento step-scheduling, los operadores condicionales se aplican a éstos. Los operadores condicionales que reciben soporte son: AND, OR.
returncode-expression no     Se utiliza en códigos step-scheduling para decidir si un paso del trabajo por lotes se ejecuta en base a los códigos de retorno de otros pasos de trabajo.
returncode-expression no   paso Nombre de paso cuyo código de retorno se va a comparar en esta expresión.
returncode-expression no   operador Operador que se va a utilizar para la expresión de código de retorno. Los operadores soportados son eq (igual que), lt (menor que), gt (mayor que), le (menor o igual que) y ge (mayor o igual que).
returncode-expression no   value El valor con el que se va a comparar el código de retorno.
step-scheduling-criteria no     Describe la secuencia en la que se procesarán los pasos de trabajo. Actualmente, la planificación secuencial recibe soporte; por ejemplo, los pasos se invocan en el orden en el que existen en xJCL.
step-scheduling-criteria no scheduling-mode   Secuencia en la que deben invocarse los pasos, siendo secuencial el único valor posible en estos momentos.
checkpoint-algorithm no     Declara un algoritmo de punto de control que puede utilizarse para un paso de trabajo por lotes.
checkpoint-algorithm no   nombre Nombre de algoritmo.
checkpoint-algorithm no classname   Clase que implementa este algoritmo.
checkpoint-algorithm no props Consulte el elemento props Secuencia de elementos prop para el algoritmo de punto de control.
checkpoint-algorithm-ref no     Referencia al elemento de un algoritmo de punto de control.
checkpoint-algorithm-ref no   nombre Nombre del algoritmo de punto de control al que se hace referencia.
checkpoint-algorithm-ref no props Consulte el elemento props. Secuencia de elementos prop para el algoritmo de punto de control.

++ El elemento substitution-props de xJCL se trata en la sección siguiente.

substitution-props de xJCL

El xJCL del trabajo puede contener variables simbólicas. Una variable simbólica es una expresión de la forma ${nombre-variable}, que se encuentra fuera de un comentario en otro documento bien formado. Por ejemplo:
<checkpoint-algorithm-ref name="${checkpoint}" />
El elemento de xJCL, substitution-props, define los pares de nombre y valor predeterminados de variables simbólicas. A continuación figura un ejemplo del elemento substitution-props, tomado del documento postingSampleXJCL.xml:
<substitution-props>
<prop name="wsbatch.count" value="5" /> 
<prop name="checkpoint" value="timebased" />
<prop name="checkpointInterval" value="15" />
<prop name="postingsDataStream" value="${was.install.root}${file.separator}temp${file.separator}postings" />
</substitution-props>

La sustitución de las variables simbólicas se produce en el tiempo de ejecución. Durante la ejecución, la serie ${nombre-variable} se sustituye por el valor de la propiedad cuando el xJCL se somete para ejecución. Mediante el uso de las propiedades en el ejemplo anterior, la serie ${checkpoint} se sustituye por la serie time-based antes de que se someta el trabajo.

Las variables simbólicas pueden ser indirectas. Por ejemplo: name=FILENAME value=${${filename}} utilizado con el par de nombre y valor filename=postingsDataStream ofrece el mismo resultado que si se especifica name=FILENAME value=${postingsDataStream}.

Las variables simbólicas también pueden ser compuestas. Por ejemplo, name=postingsDataStream value=${was.install.root}${file.separator}temp${file.separator}postings.

Los pares de nombre y valor no tienen que definirse en el elemento substitution-props del documento de trabajo. Los pares de nombre y valor de props definidos en el elemento substitution-props son valores predeterminados de las variables con nombre. Si no se definen en el elemento substitution-props, los pares de nombre y valor se deben pasar mediante las API del Planificador de trabajos cuando se somete el trabajo o definirse en las propiedades del sistema para la JVM. Todas las variables simbólicas definidas en el cuerpo de un documento de trabajo se deben resolver para que el xJCL se considere válidos. Todos los pares de nombre y valor definidos en el documento de trabajo deben resolverse con una variable simbólica que se encuentra en el cuerpo del xJCL para que el xJCL se considere válido.

Si los pares de nombre y valor se definen en el documento xJCL y se pasan a las API del planificador de trabajos durante el sometimiento, los pares de nombre y valor pasados mediante las API del planificador de trabajos alteran temporalmente los valores predeterminados definidos en el documento xJCL. Si los pares de nombre y valor no se pasan mediante las API del planificador de trabajos ni se definen como valores predeterminados del documento xJCL, los pares de nombre y valor de las variables simbólicas deben definirse en las propiedades de JVM del sistema para que el xJCL se considere válido.

Las variables simbólicas se resuelven mediante el planificador de trabajos antes del sometimiento de trabajos, excepto para las siguientes variables especiales, que se resuelven en el punto final de trabajo de larga duración. Los siguientes variables especiales deben estar todas definidas como propiedades del sistema de JVM. Son:
  • ${was.install.root}
  • ${user.install.root}
  • ${agent.home}

Icon that indicates the type of topic Concept topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cgrid_xdbatchjcl
File name: cgrid_xdbatchjcl.html