Nombre de fichero flexible/Escritura de varios ficheros

Los datos se escriben por defecto en el nombre de fichero definido en el parámetro de lote. El nombre de fichero soporta varias variables de sustitución dinámicas, como se define en la descripción detallada del parámetro de lote del control de lotes Plantilla de extracción basada en plug-in (F1-PDBEX). Puede consultar también Procesamiento de registros de extracción para obtener más información sobre el nombre de fichero y los procesos con varios threads.

El sistema también soporta una creación de ficheros más avanzada para una sola ejecución por lotes. Tenga en cuenta los casos de uso siguientes:

Se produce una extracción para datos asociados con varios proveedores de servicios y cada proveedor recibirá su propio fichero. En este caso de uso, la unidad de trabajo es el proveedor de servicios, de manera que se crea un fichero para cada unidad de trabajo.
Una implantación opera con varias jurisdicciones representadas por División SIC. Una extracción concreta dará como resultado un fichero por división, de manera que cada división solo obtiene sus datos relevantes.
Una extracción de información sobre personas debe separar los datos personales de los datos laborales de la persona. Además, para cada persona, la información de contacto se incluirá en un fichero distinto. En este caso de uso, una unidad de trabajo incluye datos que se van a escribir en más de un fichero.

Para soportar los casos de uso anteriores, el algoritmo de proceso de registros soporta la devolución del nombre del fichero en la salida:

El nombre del fichero se incluye en el grupo de instancias de esquema de la salida. Puede rellenarlo si desea que los datos específicos de una entrada de esquema se incluyan en el nombre del fichero. En el ejemplo anterior de la extracción de datos de personas, el esquema que incluye la información de contactos indicará el fichero de contactos específico.
El nombre del fichero es un campo de salida fuera de la lista de esquemas. Debe rellenarlo si no tiene diferentes ficheros para distintos esquemas pero desea sustituir el nombre del fichero definido en el parámetro de lote. Los ejemplos de proveedor de servicios y división anteriores rellenarán este parámetro con el nombre de fichero deseado. El ejemplo de extracción de datos de personas puede rellenar este campo para toda la información que no es de contactos.

El proceso por lotes comprueba la salida después de cada llamada al algoritmo de proceso de registros. Para cada esquema, si hay un nombre de fichero específico asociado al esquema, los datos de dicho esquema se escriben en ese fichero. De lo contrario, si se indica el nombre del fichero de salida, los datos se escriben en ese fichero. Si no, se utilizará el nombre del fichero del parámetro de lote.

Nota: variables de sustitución. Tras la llamada al algoritmo de proceso de registros, si hay variables de sistema en el nombre del fichero, se resuelven en este momento.

Gestión de nombres de fichero

Este tipo de requisitos implica que el algoritmo de proceso de registros tiene que proporcionar un nombre de fichero que tenga algún valor de negocio para distinguirlo de los ficheros individuales. Por ejemplo, el valor del proveedor de servicios, división o tipo de persona debe ser parte del nombre del fichero. Sin embargo, se recomienda que el algoritmo no determine por completo el nombre del fichero. Le sugerimos que permita que el usuario ejecute la tarea por lotes para obtener un nombre de fichero deseado como un parámetro de lote. De ese modo, puede incluir cualquiera de las variables de sustitución soportadas para la información de sistema (por ejemplo, el número de ejecución por lotes o el registro de fecha/hora) que garanticen que los ficheros son únicos para una determinada ejecución por lotes. El algoritmo puede designar una variable de sustitución que busque para sustituirla por el valor de negocio.

Por ejemplo, utilizando el caso de uso de los ficheros por división, imagine que el usuario indica el nombre de fichero EXTRACT_FILE_<DIV>_{BN}_{RN}_{TN}.csv. El algoritmo de proceso de registros recibe este parámetro. Sabe buscar "<DIV>" y sustituirlo por la división real. Supongamos que el código de división es A100, devolverá el nombre de fichero EXTRACT_FILE_A100_{BN}_{RN}_{TN}.csv en su salida, junto con los datos que se escriben en ese fichero para esta unidad de trabajo.

En el caso de uso de información de personas anterior, en el que hay dos ficheros, se sugiere utilizar el parámetro Nombre de fichero para uno de los ficheros, por ejemplo, el fichero de información de personas. Se debe utilizar un parámetro adicional para definir el segundo fichero, el de información de contactos. De esta forma, los usuarios que ejecutan la tarea por lotes definirán los parámetros siguientes:


Nombre de parámetro	Descripción	Valor	Comentarios
fileName	Nombre de fichero	persons_<personType>_{BN}.txt	Parámetro de nombre de fichero proporcionado en la extracción.
contactFileName	Nombre de fichero de contactos	contacts_{BN}.txt	Parámetro especial definido por el control de lotes de extracción de CM.

El algoritmo de proceso de registros debe buscar el parámetro Nombre de fichero proporcionado como entrada, localizar el texto "<personType>", sustituirlo por el valor de tipo de persona y devolver el nombre de fichero en la salida. Cuando se crea la lista de esquemas para devolver en la salida, el que incluye la información de contacto de la persona debe incluir el nombre de fichero encontrado en el parámetro Nombre de fichero de contactos proporcionado como entrada.

Varios threads

Esta funcionalidad funciona según lo previsto con varios threads. En función del caso de uso y la implantación del algoritmo de selección de registros, cada thread puede generar ficheros para el mismo valor de negocio. Vamos a utilizar el caso de uso de divisiones. Imaginemos que una implantación tiene tres divisiones: A100, B200, C300. Supongamos ahora que la extracción corresponde a información financiera de una cuenta. El algoritmo de selección de registros debe utilizar threads por ID de cuenta, de manera que los datos se distribuyan de manera uniforme a los diversos threads. Pero dentro de cada thread, las cuentas pueden estar en cualquiera de las 3 divisiones de la implantación. De este modo, cada thread podría generar 3 ficheros para cada una de las 3 divisiones.

Como se describe en Extracción de varios threads, el sistema soporta una opción para concatenar, lo cual le permite consolidar los ficheros de forma que tenga 3 ficheros completos para las 3 divisiones. Las mismas funciones y limitaciones descritas en ese tema se aplican a este caso de uso.

Cierre de ficheros

Un aspecto importante a tener en cuenta cuando se utiliza esta funcionalidad es que se debe prestar atención a cuántos ficheros están abiertos durante el proceso por lotes. Cada fichero abierto consume memoria para gestionarlo. De ese modo, el producto ha impuesto un límite de solo 10 ficheros abiertos, por thread, durante la ejecución de la tarea por lotes. Cuando se diseña un lote para escribir en varios ficheros, el producto aconseja diseñar el proceso de manera que, siempre que sea posible, se escriban todos los datos de un fichero y se cierre este antes de ir al fichero siguiente.

Echemos un vistazo a nuestros ejemplos.

En el ejemplo de proveedor de servicios, la unidad de trabajo del proceso por lotes es proveedor de servicios. En este caso, después de cada llamada al algoritmo de proceso de registros, se pueden escribir los datos en el fichero y, a continuación, cerrar el fichero.
En el ejemplo de división, los datos seleccionados deben ser gestionados mediante threads por la unidad de trabajo adecuada con relación a la finalidad de la extracción, por ejemplo Cuenta o Activo. Pero los datos deben ordenarse por división, de manera que todos los datos de cada división se procesen antes que los datos de la siguiente división. El fichero de cada división se puede cerrar una vez que se empiezan a procesar los datos de la siguiente división.
En el ejemplo de extracción de datos de personas, el fichero de contactos se utiliza para todos los datos, de manera que ese fichero tiene que permanecer abierto durante toda la tarea. Sin embargo, la información sobre personas se segrega por tipo de persona. La selección de registros puede ordenar los datos por tipo de persona, de manera que se pueden escribir todos los datos para un tipo y, después, todos los datos para el otro tipo. Sin embargo, dado que no se pueden abrir más de 3 ficheros en una ejecución, en este caso de uso no se necesita gestionar de forma activa el cierre de ficheros durante el proceso.

¿Cómo sabe el programa de lotes cuándo debe cerrar un fichero? Como el programa de lotes es agnóstico y no sabe qué tipo de datos se están procesando ni cuándo se tienen que cerrar los ficheros, el algoritmo de proceso de registros debe proporcionar esta información.

Nota: el proceso por lotes emitirá un error si el proceso de registros indica que el fichero en el que hay que escribir ya se ha cerrado. No se permite reabrir ficheros cerrados. Se debe revisar el diseño del proceso si se recibe este error.

Para gestionar esto, el proceso por lotes proporciona al algoritmo de proceso de registros una lista de los ficheros abiertos (con las variables de sustitución del sistema sin resolver) y un booleano para marcar si se debe cerrar el fichero. Para explicarlo con más detalle, vamos a utilizar nuestros ejemplos.

Ejemplo de fichero por división

En este caso de uso hay 4 divisiones en la implantación: NORTH, EAST, SOUTH, WEST y los datos (datos de cuenta) se agrupan en ficheros independientes por división.

Se recomienda que el algoritmo de selección de registros seleccione los datos ordenados por división.

El proceso por lotes pasa al algoritmo de proceso de registros la lista de ficheros abiertos (debería haber uno o ninguno). En este caso, la única indicación de que los datos de una división han finalizado se produce si el algoritmo de proceso de registros comprueba que sus datos son para una división y el fichero abierto de la lista corresponde a una división distinta. Cada llamada debe preparar el nombre de su fichero. A continuación, debe comprobar si dicho nombre está en la lista de ficheros abiertos. Si no está, esto indica que el otro fichero abierto debe cerrarse. Tenga en cuenta que no tiene que añadirse a sí mismo a la 'lista de abiertos'. El programa por lotes solo busca entradas marcadas como cerradas. Ignorará aquellas entradas que no lo estén.

Supongamos que el nombre del fichero en el parámetro de lote es myFile_<DIV>_{BN}.txt

Los datos se ordenan de tal manera que las cuentas de la división EAST se procesen primero. Imaginemos que se trata de una unidad de trabajo que también está en la división EAST. Recibirá el nombre del fichero y la lista de ficheros abiertos.

...
<hard>
<batchParms>
  <BatchParm>
    <name>fileName</name>
    <value>myFile_<DIV>_{BN}.txt</value>
  </BatchParm>
  ...
</batchParms>
<openFiles>
  <OpenFile>
    <closeFile></closeFile>
    <fileName>myFile_EAST_{BN}.txt</fileName>
  </OpenFile>
</openFiles>
...
</hard>

El algoritmo sustituye su división en la parte <DIV> del fichero y lo rellena en la salida. A continuación, compara el nombre de su fichero con la lista actual de ficheros abiertos. Lo encuentra, así que no tiene que hacer nada más.


<hard>
...
<fileName>myFile_EAST_{BN}.txt</fileName>
...
<openFiles>
  <OpenFile>
    <closeFile></closeFile>
    <fileName>myFile_EAST_{BN}.txt</fileName>
  </OpenFile>
</openFiles>
...
</hard>

Si imaginamos ahora una llamada al algoritmo de proceso de registros donde la división es NORTH y es la primera entrada para dicha división, esto es lo que recibirá:


<hard>
<batchParms>
  <BatchParm>
    <name>fileName</name>
    <value>myFile_<DIV>_{BN}.txt</value>
  </BatchParm>
  ...
</batchParms>
<openFiles>
  <OpenFile>
    <closeFile>true</closeFile>
    <fileName>myFile_EAST_{BN}.txt</fileName>
  </OpenFile>
</openFiles>
...
</hard>

El algoritmo sustituye su división en la parte <DIV> del fichero y lo rellena en la salida. A continuación, compara el nombre de su fichero con la lista actual de ficheros abiertos y no lo encuentra. Esto indica que el fichero abierto existente se tiene que cerrar.


<hard>
...
<fileName>myFile_NORTH_{BN}.txt</fileName>
...
<openFiles>
  <OpenFile>
    <closeFile>true</closeFile>
    <fileName>myFile_EAST_{BN}.txt</fileName>
  </OpenFile>
</openFiles>
...
</hard>

Ejemplo de fichero por proveedor de servicios

En este caso de uso, la unidad de trabajo es el proveedor de servicios y cada proveedor debe tener su propio fichero. En este caso, mientras el algoritmo de proceso de registros prepara los datos y el nombre de fichero exclusivo de su proveedor de servicios, también puede indicar que se puede cerrar el fichero. No es preciso esperar a la siguiente llamada al algoritmo de proceso de registros para que indique que se puede cerrar el fichero anterior. Supongamos que el nombre del fichero es MYFILE_<serviceProvder>_{BN}_{TN}.txt. Cada llamada al algoritmo de proceso de registros pasará el nombre del fichero de parámetro de lote y ningún fichero abierto.


<hard>
<batchParms>
  <BatchParm>
    <name>fileName</name>
    <value>MYFILE_<serviceProvider>_{BC}_{TN}.txt</value>
  </BatchParm>
  ...
</batchParms>
<openFiles>
  <OpenFile>
    <fileName></fileName>
    <closeFile></closeFile>
  </OpenFile>
</openFiles>
...
</hard>

El algoritmo está procesando datos para el proveedor de servicios A100. Devuelve la siguiente información relacionada con el nombre del fichero, es decir, el nombre del fichero único en la salida correspondiente a este proveedor de servicios, añade su fichero a la lista de ficheros abiertos e indica que se debe cerrar. Tenga en cuenta que fichero-por-unidad de-trabajo es el único caso de uso conocido en el que el algoritmo sabrá que es la última entrada para un fichero y se cerrará solo.

<hard>
...
<fileName>MYFILE_A100_{BC}_{TN}.txt</fileName>
...
<openFiles>
  <OpenFile>
    <closeFile>true</closeFile>
    <fileName>MYFILE_A100_{BC}_{TN}.txt</fileName>
  </OpenFile>
</openFiles>
...
</hard>

Ejemplo de varios ficheros abiertos

En este ejemplo se supone que los nombres de los ficheros se definen conforme a la sección Gestión de nombres de fichero anterior. Supongamos que el diseñador de algoritmos ha decidido no cerrar activamente el fichero de información de personas puesto que nunca hay más de tres ficheros abiertos. Supongamos, también, que opta por no ordenar los datos por tipo de persona. Esto es lo que se pasa en mitad de la ejecución:

<hard>
<batchParms>
  <BatchParm>
    <name>fileName</name>
    <value>persons_<personType>_{BN}.txt</value>
  </BatchParm>
  <BatchParm>
    <name>contactFileName</name>
    <value>contacts_{BN}.txt</value>
   </BatchParm>
  ...
</batchParms>
<openFiles>
  <OpenFile>
    <fileName>persons_P_{BN}.txt</fileName>
    <closeFile></closeFile>
  </OpenFile>
   <OpenFile>
    <fileName>persons_B_{BN}.txt</fileName>
    <closeFile></closeFile>
  </OpenFile>
  <OpenFile>
    <fileName>contacts_{BN}.txt</fileName>
    <closeFile></closeFile>
  </OpenFile>
</openFiles>
...
</hard>

Una instancia de una llamada al algoritmo de proceso de registros que tiene detalles para un individuo ("P" tipo de persona).


<fileName>persons_P_{BN}.txt</fileName> 
<fileOutput>
  <listValue>
    <SchemaInstance>
      <recordXMLNode>person</recordXMLNode>
      <schemaName>CM-PersonDetail</schemaName>
      <schemaType>F1SS</schemaType>
      <fileName></fileName>
      <data>LotsOfData</data>
    </SchemaInstance>
  </listValue>
  <listValue>
    <SchemaInstance>
      <recordXMLNode>person</recordXMLNode>
      <schemaName>CM-AddressDetail</schemaName>
      <schemaType>F1SS</schemaType>
      <fileName></fileName>
      <data>LotsOfData</data>
    </SchemaInstance>
  </listValue>
  <listValue>
    <SchemaInstance>
      <recordXMLNode></recordXMLNode>
      <schemaName>CM-ContactDetail</schemaName>
      <schemaType>F1SS</schemaType>
      <fileName>contacts_{BN}.txt</fileName>
      <data>LotsOfData</data>
    </SchemaInstance>
  </listValue>
</fileOutput>

Este ejemplo XML muestra los puntos siguientes:

Hay un nombre de fichero de sustitución en el elemento fileName.
Los dos primeros esquemas no tienen ningún valor en fileOutput\listValue\SchemaInstance\fileName, así que se deben escribir en el fichero en fileName. Observe que estos dos esquemas también incluyen un nodo XML de registro. Esto garantiza que si la salida tiene el formato XML, el nodo XML 'persona' encapsulará los datos de ambos esquemas. No es funcionalidad relacionada con este tema. Tan solo intentamos ilustrar varias funciones.
El tercer esquema tiene una entrada en fileOutput\listValue\SchemaInstance\fileName. De este modo, los datos se escriben en un fichero distinto.