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.
Elemento | Proceso intensivo de Java EE | Proceso por lotes de Java EE | Subelemento | Atributos | Descripción |
---|---|---|---|---|---|
job | sí | sí | Ámbito de la descripción de un trabajo por lotes. | ||
job | sí | sí | 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 | sí | sí | accounting | Atributo de información de cuenta opcional. | |
job | sí | sí | class | Atributo de clase de trabajo opcional, que identifica la clase de trabajo bajo la que se ejecuta el trabajo. | |
job | sí | sí | 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 | sí | sí | 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 | sí | sí | 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 | sí | sí | step-scheduling criteria | Consulte el elemento step-scheduling-criteria | |
job | no | sí | checkpoint algorithm | Consulte el elemento checkpoint-algorithm | |
job | no | sí | results-algorithm | Consulte el elemento de algoritmos de resultados | |
job | sí | sí | 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í* | sí | nombre | Nombre del paso opcional. Esta información se devuelve en los mandatos operativos. | |
job-step | sí* | 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 | sí | 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 | sí | sí | classname | Nombre plenamente cualificado de la clase que implementa el trabajo con una actividad de proceso intensiva. | |
job-step | sí | 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 | sí | 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 | sí | 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 | sí | sí | 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 | sí | sí | Instancia única de un par de nombre y valor que sirve de propiedad. | ||
prop | sí | sí | nombre | Nombre de la propiedad. | |
prop | sí | sí | value | Valor de la propiedad. | |
props | sí | sí | 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 | sí | Instancia única de implementación de una secuencia de datos por lotes a la que puede acceder el trabajo por lotes. | ||
bds | no | sí | 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 | sí | impl-class | Nombre de clase plenamente cualificado de la clase de implementación de la secuencia de datos por lotes. | |
bds | no | sí | 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 | sí | Serie de elementos bds | ||
batch-data-streams | no | sí | bds | Consulte el elemento bds | |
step-scheduling | no | sí | 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 | sí | returncode- expression | Consulte el elemento returncode-expression | Expresión Returncode- a evaluar. |
step-scheduling | no | sí | 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 | sí | 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 | sí | paso | Nombre de paso cuyo código de retorno se va a comparar en esta expresión. | |
returncode-expression | no | sí | 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 | sí | value | El valor con el que se va a comparar el código de retorno. | |
step-scheduling-criteria | no | sí | 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 | sí | scheduling-mode | Secuencia en la que deben invocarse los pasos, siendo secuencial el único valor posible en estos momentos. | |
checkpoint-algorithm | no | sí | Declara un algoritmo de punto de control que puede utilizarse para un paso de trabajo por lotes. | ||
checkpoint-algorithm | no | sí | nombre | Nombre de algoritmo. | |
checkpoint-algorithm | no | sí | classname | Clase que implementa este algoritmo. | |
checkpoint-algorithm | no | sí | props | Consulte el elemento props | Secuencia de elementos prop para el algoritmo de punto de control. |
checkpoint-algorithm-ref | no | sí | Referencia al elemento de un algoritmo de punto de control. | ||
checkpoint-algorithm-ref | no | sí | nombre | Nombre del algoritmo de punto de control al que se hace referencia. | |
checkpoint-algorithm-ref | no | sí | 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
<checkpoint-algorithm-ref name="${checkpoint}" />
<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.
- ${was.install.root}
- ${user.install.root}
- ${agent.home}