128 lines
6.8 KiB
Markdown
128 lines
6.8 KiB
Markdown
# 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`.
|