# Fluxul actualizarii ROA si al buletinului informativ

Referinta de ansamblu: cine cheama pe cine, de pe ce masina si cu ce fisiere. Pentru depanare
mergi la `depanare-pack-update.md` (baza clientului) si `depanare-server-update-roa.md`
(serverul care livreaza).

## Masinile

| Rol | Masina | Ce ruleaza |
|---|---|---|
| baza clientului | serverul Oracle al clientului | jobul `UPDATEROA_ZILNIC` -> `CONTAFIN_ORACLE.PACK_UPDATE` |
| serverul de actualizari | **ROACENTRAL**, 10.0.20.122 | IIS + ActiveVFP, `D:\APPUPDATESERVERAVFP`; rutele `updroa` |
| baza centrala | **ROA_CENTRAL**, 10.0.20.121 | `SOFT_SERII` (contracte, clienti), `CONTAFIN_ORACLE` (`UPD_DATABASE`, scripturi) |
| proxy public | 10.0.20.36 | `roa.romfast.ro` -> ROACENTRAL |
| SMTP | `mail.romfast.ro` = 185.141.190.195 | Exim (a2hosting), **cerut cu TLS** |

## 1. Actualizarea, pe client

`UPDATEROA_ZILNIC` -> `PACK_UPDATE.UpdateROA`, trei etape secventiale; una esuata le opreste pe
urmatoarele si starea ramane in `UPD_ISTORIC` (`0` start, `1` aplicatii, `2` scripturi, `3`
aplicare, `4` incheiat):

1. **UpdateApp** - descarca `roa_app.xml` / `roastart_app.xml` (lista de versiuni) si arhivele
   programelor cu versiune mai noua, in directoarele Oracle `UPD_<PROGRAM>`; la final cere
   serverului trimiterea buletinului informativ (vezi mai jos).
2. **UpdateScripts** - descarca `roa_database.xml` + arhivele de scripturi si umple `UPD_DATABASE`.
3. **UpdateDatabaseSqlPlus** - genereaza in `DMPDIR` (`C:\DMPDIR`) `script_<SCHEMA>.sql` +
   `script_master.sql` si le da unui SQL*Plus extern; iesirea in `C:\DMPDIR\script_master.log`
   (erorile de aici **nu** ajung in `UPD_LOG`).

Logul rularii curente e in `UPD_LOG` (se goleste la fiecare rulare); esecul real al jobului in
`dba_scheduler_job_run_details`.

### Cum se descarca, de fapt

```
PACK_UTILS.URL2Clob / URL2Blob
  daca SERVER_INFO.POWERSHELLDOWNLOAD = 1:
    -> PACK_UTILS.DownloadFileOS
         scrie in DMPDIR un script ps (download_<timestamp>.ps1; inainte de
         co_2026_09_16_02_COMUN_PACK_UTILS era un nume fix, download_file.ps1)
      -> sys.ExecuteScriptOS (job scheduler 'executable', asincron)
      -> powershell -ExecutionPolicy Bypass -File <script>
      -> curl.exe -k -o "<fisier>.part" "<url>"; la exit 0, Move-Item pe numele final
      -> asteapta max SERVER_INFO.POWERSHELLTIMEOUT secunde sa apara fisierul final
  daca fisierul nu apare (sau POWERSHELLDOWNLOAD <> 1):
    -> HTTPURITYPE.createuri(url).getclob()/getblob()   <- pe https nu poate functiona fara wallet
```

Descarcarea in `.part` cu redenumire la final a fost introdusa de
`co_2026_09_16_02_COMUN_PACK_UTILS` (16.09.2026). Inainte, bucla iesea din prima secunda pentru ca
`curl` creeaza fisierul gol la inceputul cererii si il tine deschis: citirea lui dadea
**ORA-29283**, iar stergerea **ORA-29291**, si actualizarea se oprea. Tot atunci:
`PACK_UTILS_FILE.FileDelete` a devenit best-effort si `PACK_UPDATE.EmailLog` nu mai ridica
`ORA-20000` peste eroarea reala.

URL-urile vin din `OPTIUNI.UPD_URL_APP`, `UPD_URL_DATABASE`, `UPD_URL_BULETININF` (daca lipsesc,
din default-urile din cod), cu `|CUSTOMERID|` inlocuit din `sys.auth_detalii.detalii`.

## 2. Rutele de pe serverul de actualizari

`D:\APPUPDATESERVERAVFP\prg\rest\controllers\updroa.prg`, chemate prin
`.../contafinupdate/default.aspx/updroa/<ruta>/<parametri>`:

| Ruta | Ce face |
|---|---|
| `download/<customerid>/<fisier>` | serveste `roa_app.xml`, `roastart_app.xml`, `roa_database.xml`, arhivele de programe si de scripturi din `D:\ROAUPDATE\_UPDATE\` |
| `buletin_informativ/<id_client>` | **compune si trimite** emailul de buletin catre clientul respectiv; intoarce un text de stare |

`updroa.prg` **nu se compileaza**: ActiveVFP compileaza `.prg`-ul din mers. Directorul e o copie de
lucru SVN (`http://svnroa:3001/svn/fox/Appupdate/activevfp`), deci modificarile se vad imediat, iar
`svn diff` / `svn revert` sunt plasa de siguranta.

Ambele rute trec intai prin `GetCustomer`, care interogheaza
`SOFT_SERII.VGEN_CONTRACTESUPORTTEHNIC` pe ROA_CENTRAL (view care ia datele contractului peste db
link `DBL_ROMFAST2` -> 10.0.20.36) si tine un cache local in `D:\APPUPDATESERVERAVFP\data\contracte.dbf`.

Log-ul aplicatiei: `D:\APPUPDATESERVERAVFP\prg\rest\controllers\log.txt` (fiecare cerere se
incheie cu `<id_client> | <mesajul returnat>`). Loguri IIS: `C:\inetpub\logs\LogFiles\W3SVC1\`.

## 3. Cele doua emailuri - nu se confunda

| | Log de actualizare | Buletin informativ |
|---|---|---|
| Cine trimite | **baza clientului**, `PACK_UPDATE.EmailLog`, `UTL_SMTP` direct | **serverul de actualizari**, `SendViaCDOSYS` din `prg\utility\sendemail.prg` |
| Cand | doar pe esecul actualizarii | la finalul etapei `UpdateApp`, prin GET pe `UPD_URL_BULETININF` |
| Catre | `SERVER_INFO.EMAIL_TO` + `EMAIL_CC` | adresa clientului din `customers.email` (ROA_CENTRAL), cu BCC `office@romfast.ro` |
| Continut | liniile din `UPD_LOG` | raport HTML generat de server |
| Ce vede clientul in `UPD_LOG` | - | raspunsul HTTP, verbatim |

Un buletin esuat nu opreste actualizarea: raspunsul (`ERR-1-...`) e text normal, se scrie in
`UPD_LOG` si fluxul merge mai departe.

### SMTP: de ce trebuie TLS

`mail.romfast.ro` **nu anunta `AUTH` pe sesiune necriptata**. Fara TLS, CDOSYS trimitea
neautentificat, iar pentru sesiuni neautentificate Exim verifica numele din `EHLO`: ROACENTRAL e in
`WORKGROUP`, fara sufix DNS, deci CDOSYS trimitea `EHLO ROACENTRAL` si primea
`550 Access denied - Invalid HELO name`. Niciun buletin nu a plecat intre 20.04.2026 si 16.09.2026.

Configuratia corecta (`sendemail.prg`, `SendViaCDOSYS`): `smtpserverport = 465`,
`smtpusessl = .T.`, `smtpauthenticate = 1` + user/parola. Cu TLS si autentificare, acelasi
`EHLO ROACENTRAL` e acceptat, deci **nu e nevoie de sufix DNS pe masina si nici de repornire**.

Verificare rapida, de pe serverul de trimitere (nu trimite nimic, doar deschide sesiunea):

```powershell
# 465, implicit SSL: dupa AUTH LOGIN trebuie "235 Authentication succeeded", apoi MAIL FROM -> 250
```

Test cap-coada fara sa deranjezi un client: clientii `1` si `22` sunt ROMFAST S.R.L.
(`customers.id = 1701`, email `office@romfast.ro`), deci buletinul lor ajunge la noi:

```powershell
curl.exe -s "http://localhost:81/contafinupdate/default.aspx/updroa/buletin_informativ/22"
# -> BULETIN INFORMATIV TRIMIS CU SUCCES <data>
```

### Raspunsurile rutei de buletin

`BULETIN INFORMATIV TRIMIS CU SUCCES <data>` | `ERR-1-BULETIN INFORMATIV NU S-A TRIMIS. MOTIVUL: ...`
| `ERR-1-CONTRACT DE SUPORT TEHNIC INEXISTENT` | `ERR-0-EROARE DE CONECTARE SQL ...` |
`OK-0-NU EXISTA MODIFICARI DE RAPORTAT IN BULETINUL INFORMATIV`.

Ultimul a fost adaugat pe 16.09.2026: pana atunci, cand nu erau modificari de raportat, ruta
raspundea **200 cu corp gol** (1848 din 2948 apeluri), iar baza clientului scria o eroare la
fiecare rulare. Textul nu e parsat de nimeni - `PACK_UPDATE` doar il scrie in `UPD_LOG`.