Conceptos y arquitectura

Cómo funciona

Riversoft® STCP Gemini Rename es una utilidad de línea de comandos: se ejecuta, procesa los archivos y termina. Cada ejecución recibe un enrutamiento, que es un conjunto de reglas. Para cada archivo, Riversoft STCP Gemini Rename busca la primera regla que corresponde a él y aplica las acciones de esa regla.

Registro de los enrutamientos

El operador registra los enrutamientos en el Riversoft Console Portal, que los graba en la base de configuración por medio de la Riversoft STCP Gemini API. En el modo archivo local, el operador crea el archivo JSON de enrutamiento.

    flowchart LR
    OP[Operador] -->|modo base de datos:<br/>registra el enrutamiento| PORTAL[Riversoft<br/>Console Portal] --> API[Riversoft STCP<br/>Gemini API] -->|graba| DB[(Base de<br/>configuración)]
    OP -->|modo archivo local:<br/>crea el archivo JSON de enrutamiento| JSON[Archivo JSON<br/>de enrutamiento]
  

Activación por evento

Cuando un socio envía un archivo, Riversoft STCP Gemini Server o Riversoft STCP DirectLink activa Riversoft STCP Gemini Rename con el archivo recibido. Riversoft STCP Gemini Rename lee el enrutamiento y aplica la regla al archivo.

    flowchart LR
    PARC[Socio] -->|envía el archivo| GEM[Riversoft STCP Gemini Server<br/>o Riversoft STCP DirectLink]
    GEM -->|activa con el archivo<br/>recibido| REN[Riversoft STCP<br/>Gemini Rename]
    DB[(Base de<br/>configuración)] -->|enrutamiento| REN
    REN -->|aplica la regla| DEST[Destino]
  

Activación por agendamiento

En el horario definido, un agendamiento de la instancia o del sistema operativo ejecuta Riversoft STCP Gemini Rename con barrido (-scan). Lee el enrutamiento, recorre el directorio de origen y aplica la regla a cada archivo encontrado.

    flowchart LR
    AG[Agendamiento] -->|ejecuta el barrido| REN[Riversoft STCP<br/>Gemini Rename]
    DB[(Base de<br/>configuración)] -->|enrutamiento| REN
    DIR[Directorio<br/>de origen] -->|archivos| REN
    REN -->|aplica la regla<br/>a cada archivo| DEST[Destino]
  

Modos de configuración

El modo se define en cfgProviderType, en el archivo de configuración. Vea Configuración.

El modo base de datos es el más usado: los enrutamientos se registran en el Portal y las ejecuciones aparecen en el log de la instancia, junto con las transferencias.

Formas de ejecución

Todas las opciones están en Referencia de comandos.

Enrutamientos y reglas

Un enrutamiento tiene una parte general, con las opciones de barrido y de log, y una lista de reglas numeradas (Index) a partir de 0.

• Las reglas se evalúan en orden, y vale la primera que corresponda al archivo.
• Una regla corresponde cuando el nombre del archivo (FileRegEx), el directorio (DirRegEx) y el origen (SrcRegEx) cumplen las expresiones regulares. Opcionalmente, también se verifica el contenido de las primeras líneas (ContentRegEx).
• Una regla bloqueada (Locked) se ignora.
• La numeración debe ser continua: un hueco en el Index termina la evaluación.
• Una regla puede indicar la próxima regla a ejecutar (NextSection), lo que permite encadenar acciones sobre el mismo archivo.

La estructura completa está en Referencia de reglas.

Procesamiento de un archivo

Riversoft STCP Gemini Rename busca la primera regla que corresponde al archivo y verifica los límites de esa regla. Si ninguna regla corresponde, o si el archivo está fuera de los límites, queda en el origen.

    flowchart LR
    A[Archivo] --> B{¿Alguna regla<br/>corresponde?}
    B -- no --> X[Registra error MSG7003<br/>y el archivo queda en el origen]
    B -- sí --> C{¿Horario, día, antigüedad<br/>y tamaño permitidos?}
    C -- no --> W[Registra aviso<br/>y el archivo queda en el origen]
    C -- sí --> P[Aplica las acciones<br/>de la regla]
  

Las acciones se ejecutan en este orden. Cada etapa es opcional y solo se ejecuta cuando está configurada en la regla.

Si la etapa de comando antes de la copia, de backup antes de la copia o de copia falla, se ejecuta el comando de error (ExecProgError), cuando está configurado, y el procesamiento del archivo termina. Si la etapa de backup después de la copia o de comando después de la copia falla, también se ejecuta el comando de error, pero el procesamiento continúa. Si la regla indica una próxima regla (NextSection), esta se ejecuta sobre el mismo archivo.

    flowchart LR
    S[Etapa de la regla] -- completada --> N{¿Próxima regla<br/>definida?}
    N -- sí --> R[Ejecuta la próxima regla<br/>sobre el mismo archivo]
    N -- no --> F[Fin del archivo]
    S -- falla --> E[Comando de error<br/>ExecProgError]
    E --> T[Fin del archivo<br/>con error]
  

En el barrido, cada archivo se procesa de la misma forma. Un archivo con error no interrumpe el barrido de los demás.

Variables

Los comandos externos y los nombres de los archivos de control aceptan variables, como $FILENEWNAME (nombre completo del nuevo archivo) y $SRCUSER (usuario de origen). También pueden usarse los valores de -var0 a -var9, informados en la línea de comandos. Vea Referencia de variables.

Ejecución simultánea

Para evitar que dos ejecuciones procesen los mismos archivos al mismo tiempo:

• el barrido puede usar un semáforo (ScanLockSem): otro barrido con el mismo semáforo espera o termina;
• cada regla puede usar archivos de control (lock y unlock), creados y verificados antes y después de la copia;
• el control de lock de la aplicación se define en lockProvider, en el config.json.

Conceptos clave