romfast/comun
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
comun/docs/flux-actualizare-si-buletine.md
Marius Mutu b4d1d0bf7b sync SVN r18142
2026-09-16 15:18:44 +03:00

6.8 KiB
Raw Permalink Blame History

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):

# 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:

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.