sync SVN r18142

docs/depanare-pack-update.md

@@ -15,6 +15,9 @@ temporar in `DMPDIR`). Foloseste-l intai; sectiunile de mai jos explica ce cites
 Cand cauza e spatiul (tablespace plin, audit/loguri Oracle care umplu discul), continua cu
 `depanare-spatiu-oracle.md` si `COMUN\utile\diag_spatiu.ps1`.
 
+Fluxul complet (ce ruleaza pe ce masina, rutele serverului, cele doua emailuri):
+`flux-actualizare-si-buletine.md`.
+
 Cand eroarea e de retea/HTTP (`ORA-29273` / `ORA-29024` / descarcare esuata), cauza e aproape sigur
 pe serverul de actualizari, nu pe client: continua cu `depanare-server-update-roa.md`.
 

docs/depanare-server-update-roa.md

@@ -5,14 +5,16 @@ de ce se intampla **pe serverul care livreaza actualizarile**. Foloseste documen
 `PACK_UPDATE` esueaza cu erori de retea / HTTP, adica atunci cand clientul e in regula dar nu
 primeste fisierele.
 
+Ansamblul fluxului, fara depanare: `flux-actualizare-si-buletine.md`.
+
 ## Lantul complet, de la eroare la cauza
 
 ```
 job UPDATEROA_ZILNIC -> PACK_UPDATE.UpdateROA
   -> PACK_UTILS.URL2Clob / URL2Blob
        daca SERVER_INFO.POWERSHELLDOWNLOAD = 1:
-         -> PACK_UTILS.DownloadFileOS -> scrie C:\DMPDIR\download_file.ps1
+         -> PACK_UTILS.DownloadFileOS -> scrie C:\DMPDIR\download_<timestamp>.ps1 (pana la co_2026_09_16_02: download_file.ps1)
-            -> sys.ExecuteScriptOS -> powershell -> curl.exe -k -o <tmp> <url>
+            -> sys.ExecuteScriptOS -> powershell -> curl.exe -k -o <tmp>.part <url>, redenumit la final (pana la co_2026_09_16_02: direct in <tmp>)
             -> asteapta max SERVER_INFO.POWERSHELLTIMEOUT secunde sa apara <tmp>
        daca fisierul NU apare (sau POWERSHELLDOWNLOAD <> 1):
          -> cade pe HTTPURITYPE.createuri(url).getclob()/getblob()
@@ -46,7 +48,7 @@ curl.exe -k -s -o NUL --max-time 20 -w "HTTP=%{http_code} t=%{time_total}" "http
 
 `HTTP=000` cu `t` egal cu `--max-time` = blocat (nu refuzat). `exit=28` = timeout.
 
-Ultima comanda reala rulata de Oracle e in **`C:\DMPDIR\download_file.ps1`** pe serverul clientului
+Ultima comanda reala rulata de Oracle e in **`C:\DMPDIR\download_*.ps1`** (un singur fisier, cu nume fix, pana la co_2026_09_16_02) pe serverul clientului
 - contine URL-ul exact si numele fisierului tinta. Daca `.tmp`-ul corespunzator nu exista, stii
 sigur ca descarcarea a picat.
 
@@ -165,7 +167,7 @@ Dupa kill, totul revine imediat - nu e nevoie de restart de sit sau de recycle d
 ## Lista scurta de verificare
 
 1. `user_scheduler_job_run_details` pe clientul afectat: care e eroarea reala si **din ce zi**.
-2. `C:\DMPDIR\download_file.ps1` pe client: URL-ul exact; exista `.tmp`-ul?
+2. scriptul `download_*.ps1` din `C:\DMPDIR` pe client: URL-ul exact; exista `.tmp`-ul?
 3. `curl` de pe client pe acel URL: raspunde sau timeout?
 4. Pe ROACENTRAL, `curl` local cu `--resolve`, pentru mai multi clienti: e global sau doar unul?
 5. `log.txt` al aplicatiei: pana la ce linie ajunge cererea blocata.

docs/flux-actualizare-si-buletine.md

@@ -0,0 +1,127 @@
+# 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`.