Conceitos e arquitetura

Como funciona

O Riversoft® STCP Gemini Rename é um utilitário de linha de comando: ele é executado, processa os arquivos e termina. Cada execução recebe um roteamento, que é um conjunto de regras. Para cada arquivo, o Riversoft STCP Gemini Rename procura a primeira regra que corresponde a ele e aplica as ações dessa regra.

Cadastro dos roteamentos

O operador cadastra os roteamentos no Riversoft Console Portal, que os grava no banco de configuração por meio da Riversoft STCP Gemini API. No modo arquivo local, o operador cria o arquivo JSON de roteamento.

    flowchart LR
    OP[Operador] -->|modo banco de dados:<br/>cadastra o roteamento| PORTAL[Riversoft<br/>Console Portal] --> API[Riversoft STCP<br/>Gemini API] -->|grava| DB[(Banco de<br/>configuração)]
    OP -->|modo arquivo local:<br/>cria o arquivo JSON de roteamento| JSON[Arquivo JSON<br/>de roteamento]
  

Acionamento por evento

Quando um parceiro envia um arquivo, o Riversoft STCP Gemini Server ou o Riversoft STCP DirectLink aciona o Riversoft STCP Gemini Rename com o arquivo recebido. O Riversoft STCP Gemini Rename lê o roteamento e aplica a regra ao arquivo.

    flowchart LR
    PARC[Parceiro] -->|envia o arquivo| GEM[Riversoft STCP Gemini Server<br/>ou Riversoft STCP DirectLink]
    GEM -->|aciona com o arquivo<br/>recebido| REN[Riversoft STCP<br/>Gemini Rename]
    DB[(Banco de<br/>configuração)] -->|roteamento| REN
    REN -->|aplica a regra| DEST[Destino]
  

Acionamento por agendamento

No horário definido, um agendamento da instância ou do sistema operacional executa o Riversoft STCP Gemini Rename com varredura (-scan). Ele lê o roteamento, percorre o diretório de origem e aplica a regra a cada arquivo encontrado.

    flowchart LR
    AG[Agendamento] -->|executa a varredura| REN[Riversoft STCP<br/>Gemini Rename]
    DB[(Banco de<br/>configuração)] -->|roteamento| REN
    DIR[Diretório<br/>de origem] -->|arquivos| REN
    REN -->|aplica a regra<br/>a cada arquivo| DEST[Destino]
  

Modos de configuração

O modo é definido em cfgProviderType, no arquivo de configuração. Veja Configuração.

O modo banco de dados é o mais usado: os roteamentos são cadastrados no Portal e as execuções aparecem no log da instância, junto das transferências.

Formas de execução

Todas as opções estão em Referência de comandos.

Roteamentos e regras

Um roteamento tem uma parte geral, com as opções de varredura e de log, e uma lista de regras numeradas (Index) a partir de 0.

• As regras são avaliadas em ordem, e vale a primeira que corresponder ao arquivo.
• Uma regra corresponde quando o nome do arquivo (FileRegEx), o diretório (DirRegEx) e a origem (SrcRegEx) atendem às expressões regulares. Opcionalmente, o conteúdo das primeiras linhas também é verificado (ContentRegEx).
• Uma regra bloqueada (Locked) é ignorada.
• A numeração precisa ser contínua: uma lacuna no Index encerra a avaliação.
• Uma regra pode indicar a próxima regra a executar (NextSection), o que permite encadear ações sobre o mesmo arquivo.

A estrutura completa está em Referência de regras.

Processamento de um arquivo

O Riversoft STCP Gemini Rename procura a primeira regra que corresponde ao arquivo e confere os limites dessa regra. Se nenhuma regra corresponder, ou se o arquivo estiver fora dos limites, ele fica na origem.

    flowchart LR
    A[Arquivo] --> B{Alguma regra<br/>corresponde?}
    B -- não --> X[Registra erro MSG7003<br/>e o arquivo fica na origem]
    B -- sim --> C{Horário, dia, idade<br/>e tamanho permitidos?}
    C -- não --> W[Registra aviso<br/>e o arquivo fica na origem]
    C -- sim --> P[Aplica as ações<br/>da regra]
  

As ações são executadas nesta ordem. Cada etapa é opcional e só é executada quando está configurada na regra.

Se a etapa de comando antes da cópia, de backup antes da cópia ou de cópia falhar, o comando de erro (ExecProgError) é executado, quando configurado, e o processamento do arquivo termina. Se a etapa de backup depois da cópia ou de comando depois da cópia falhar, o comando de erro também é executado, mas o processamento continua. Se a regra indicar uma próxima regra (NextSection), ela é executada sobre o mesmo arquivo.

    flowchart LR
    S[Etapa da regra] -- concluída --> N{Próxima regra<br/>definida?}
    N -- sim --> R[Executa a próxima regra<br/>sobre o mesmo arquivo]
    N -- não --> F[Fim do arquivo]
    S -- falha --> E[Comando de erro<br/>ExecProgError]
    E --> T[Fim do arquivo<br/>com erro]
  

Na varredura, cada arquivo é processado da mesma forma. Um arquivo com erro não interrompe a varredura dos demais.

Variáveis

Os comandos externos e os nomes dos arquivos de controle aceitam variáveis, como $FILENEWNAME (nome completo do novo arquivo) e $SRCUSER (usuário de origem). Os valores de -var0 a -var9, informados na linha de comando, também podem ser usados. Veja Referência de variáveis.

Execução simultânea

Para evitar que duas execuções processem os mesmos arquivos ao mesmo tempo:

• a varredura pode usar um semáforo (ScanLockSem): outra varredura com o mesmo semáforo espera ou termina;
• cada regra pode usar arquivos de controle (lock e unlock), criados e conferidos antes e depois da cópia;
• o controle de lock do aplicativo é definido em lockProvider, no config.json.

Conceitos-chave