Table of Contents

Debugging (guida per sviluppatori)

Guida al debug dello stack Infocad, con il verticale RequestCenter / Service Desk come esempio tracciato end-to-end. Copre: avvio FE/BE in debug, come seguire una richiesta dal frontend al BL/DAL/stored procedure, ispezione della configurazione (connection string via ConnectionsService), cattura della procedura/SQL generata, localizzazione dei log, diagnosi dei fallimenti di autorizzazione, transazioni, integrazione (WCF / .NET Remoting) e job in background.

Confidence complessiva: SUPPORTED (catene di codice lette sul sorgente) · comandi Windows/IIS/msbuild marcati NON verificati su questo host (macOS, senza Oracle Client — cfr. regole di programma §8).

Premessa sull'ambiente

Lo stack è Windows-centric (ODP.NET unmanaged Oracle.DataAccess, WCF, ASP.NET Web Forms, Windows Services). Un debug "vero" del percorso 4.8 richiede Windows + Visual Studio 2022 (o Build Tools) + un Oracle Client e un backend Oracle raggiungibile (REQUESTCENTER_TEST38 / DEM_TEST38 / INFOCAD_TEST38 / ASPNET). INFERRED

  • Su un host non-Windows si compilano solo i progetti *XNET (net8.0); i progetti del verticale RequestCenter non chiudono le dipendenze headless (RequestCenterXNET → assembly 4.8 solo-Windows Descor.Stock.* / *.Controllers). VERIFIED
  • I comandi msbuild/iisexpress/attach a w3wp.exe in questa pagina sono riportati come riferimento e vanno considerati NON verificati su questo host.

1. Avviare FE/BE in debug

Frontend Web Forms (RequestCenter) — Windows/IIS NON-verificato

RequestCenterWeb è un'app ASP.NET Web Forms ospitata come virtual directory sotto la shell CASSANDRA (Default.aspx è la shell-page che carica dinamicamente gli UserControl).

  1. Aprire InfocadWeb/WebMachine/WebMachine.sln in Visual Studio 2022.
  2. Build (msbuild ... -p:Configuration=Debug — vedi Guide per sviluppatori).
  3. Avviare l'app web CASSANDRA sotto IIS / IIS Express; Debug → Attach to Process su w3wp.exe (IIS) oppure iisexpress.exe.
  4. Breakpoint di partenza consigliato: makeTicket.ascx.vb:82 (btnPost_Click).

Backend / servizi Windows — NON-verificato

Il lavoro di background gira come Windows Services (InfocadServer, IEMServer, ECMServer, companion ConnectionsService/UpdateService/…). Per il debug di un servizio: build in Debug, installare/avviare il servizio, poi Attach to Process sull'eseguibile del servizio. SUPPORTED (modello di hosting descritto in Architettura).

Il verticale RequestCenter non passa dai Windows Services: il BL/DAL vive in-process nell'app web (o nell'host WCF), quindi il debug è per lo più attach a w3wp.exe. VERIFIED

Slice net8 (*XNET) — cross-platform

I progetti *XNET si costruiscono con dotnet build, ma per RequestCenter la chiusura delle dipendenze fallisce headless (vedi Premessa). DataManagerXNET compila net8.0 0/0 ma docfx metadata fallisce (BC30002 System.Data). VERIFIED

2. Seguire una richiesta dal frontend (walkthrough tracciato — FLOW-REQ-001)

Traccia statica completa del path di creazione ticket (create). Ogni riga è un breakpoint utile. Riferimento completo: FLOW-REQ-001.

# Punto File:riga Cosa osservare
1 Trigger submit makeTicket.ascx.vb:82 (btnPost_Click, Handles actSubmt.ActivityRun) postback del pulsante attività
2 Gate di stato :83 CheckParentStateChange() / CheckSiblingStateChange() se true → apertura alert, nessuna scrittura
3 Validazione UI :84-85 DoValidation() / ValidateUpload(...) errLog.ErrorStrings.Count
4 Protocollo :93 Parametric.RequestCenter.Protocol.GetCreationMoment → MakeProtocol(...) ramo After
5 Apertura transazione :111-112 objTransaction.OpenConnection() / Begin() inizio unità di lavoro
6 Insert richiesta :114 RequestCenter.Ticket.Request.Create(...) ritorna idRequest
7 Set dati :120-137 SetSpatialInfo / SetManagement / SetContract / SetCompany / SetExpiry, RequestMO.Create oggetto BL popolato
8 Descrizione :185 _objRequest.WriteDescription() → DAL setDescription
9 Custom/allegati/tipo :187-203 SaveCustomFields / SaveFileUpload / SetCallType / SetType …
10 Elemento workflow :210 _currentAct.Run(iduser) → DEM.WorkflowCreatingActivity.Run ritorna newIdElement
11 Aggancio WF↔richiesta :214 _objRequest.SetWorkflowInterface(newIdElement) → DAL setWorkflowInterface
12 Commit :216 objTransaction.Commit() punto di persistenza
13 Post-commit :236 LogTicketActionOnSession(...), ProcessAlertSystem() (mail) side effects
14 Catch/rollback :238-250 objTransaction.Rollback() + InfocadTraceWrapper.CreateError(...) vedi §7
15 Finally :254 objTransaction.CloseConnection() chiusura connessione

VERIFIED — righe lette su CASSANDRA/RequestCenterWeb/UserControls/FlowActions/makeTicket.ascx.vb.

Simboli BL/DAL: Ticket.Request, RequestDAL, IRequestDAL, Transaction.

3. Seguire una chiamata BL → DAL → stored procedure

Il BL (Descor.RequestCenter.Ticket.Request, Request.vb:25) delega ogni scrittura al DAL tramite l'interfaccia IRequestDAL (Interfaces/TicketInterfaces.vb:39). L'implementazione RequestDAL.vb (246 Function pubbliche) usa un unico pattern per invocare i package Oracle:

' RequestDAL.addRequest (RequestDAL.vb:5054) -> GESTREQUEST_T2.ADDREQUEST
Dim cm As GlobalDataManager = Configuration.Settings.GetConnectionManager(True)
Dim openResult As OpenConnectionResult
' ... costruzione OracleParameter (PIDUSER, PIDTENANT, PPROTOCOL, ... , NEWREQUESTINDEX OUT) ...
openResult = cm.Open
cm.ExecuteNonQuery("GESTREQUEST_T2.ADDREQUEST", idUserParam, ... , newIndexParam)
Return DirectCast(newIndexParam.Value, Types.OracleDecimal).ToInt32

Punti di breakpoint chiave per il debug del DAL (RequestDAL.vb): addRequest:5054 / overload :5089, setDescription:5407, setWorkflowInterface:5641, closeRequest:6242, deleteRequest:6264; letture Load:18, getIdRequestListByFilter:333, getByProtocol:633, getRequestList:733. VERIFIED

  • Il "motore" è cm = Descor.DataManager.GlobalDataManager (progetto DataManager): espone Open, ExecuteNonQuery / ExecuteReader / ExecuteScalar / Fill (GlobalDataManager.vb:214,297,384,423) e la gestione transazione BeginTransaction/CommitTransaction/RollbackTransaction (:155,171,181). VERIFIED
  • Il nome comando passato a cm è sempre "PACKAGE.PROC" (es. "GESTREQUEST_T2.ADDREQUEST"): è quello il punto in cui, in debug, si legge quale stored procedure verrà eseguita. VERIFIED
  • Package coinvolti nel verticale: GESTREQUEST (~41 riferimenti) e GESTREQUEST_T2 (~9). Mappa proc→tabelle in crud-matrix e procedure REQUESTCENTER_TEST38. SUPPORTED

Driver Oracle selezionato dalla guardia di compilazione

RequestDAL.vb:3 usa #If NET5_0_OR_GREATER Then Imports Oracle.ManagedDataAccess.Client … #Else Imports Oracle.DataAccess. In build net48 (RequestCenter.DAL.OracleODP) gira il driver unmanaged Oracle.DataAccess; in build net8 (RequestCenter.DAL.OracleODPXNET) il managed Oracle.ManagedDataAccess.Core 23.4.0. In debug, verificare quale binario è caricato prima di ipotizzare problemi di driver/pool. VERIFIED

4. Ispezionare la configurazione (connection string)

Le connection string non sono editate a mano per app: al deploy, ConnectionsService (InfocadServer) legge un connections.xml e riscrive <connectionStrings> (e applicationName dei provider Oracle Membership/Role) nel *.exe.config/Web.config target, poi riavvia il servizio. Connessioni note: MainConnection, RequestCenterConnection, DEMConnection, OracleProvidersDB. SUPPORTED (vedi Guide per sviluppatori, Operations).

In debug il connection manager cm viene risolto da RequestCenter.Configuration.Settings.GetConnectionManager (Settings.vb:242):

  • Se HttpContext.Current è presente, cm è memorizzato per richiesta nell'item "RCCONNECTIONMANAGER" (istanziato la prima volta). VERIFIED
  • Ramo WCF (#If Not NET5_0_OR_GREATER, Settings.vb:262+): quando la chiamata arriva da OperationContext.Current (nessun HttpContext), il manager viene istanziato e possono essere propagati i parametri di sessione DB (DBUSERSESSION/DBSOURCESESSION) dalle IncomingMessageProperties. VERIFIED
  • Diagnosi tipiche di connection string: vedi TS-001 (login/ORA-01017/connection string) e TS-002 (connection string vuote dopo il deploy).
Warning

SEC-001 — nelle configurazioni CASSANDRA le credenziali Oracle risultano in chiaro (Web.config). Non stampare mai credenziali durante il debug. SUPPORTED (vedi Qualità e test).

5. Catturare la procedura / SQL generata

Non c'è ORM: ogni chiamata è una stored procedure invocata via cm. Per catturare cosa viene eseguito:

  1. A livello codice — breakpoint sulla riga cm.ExecuteNonQuery("PKG.PROC", …) / cm.ExecuteReader(...) / cm.Fill(...) nel metodo DAL: la stringa è il nome package.proc e gli OracleParameter (nome, OracleDbType, Value, Direction) sono i binding. Es. RequestDAL.vb:5078. VERIFIED
  2. Parametri OUT — l'identity ritorna via parametro OUT (NEWREQUESTINDEX, Direction = Output), letto come OracleDecimal.ToInt32. Ispezionare .Value post-esecuzione. VERIFIED
  3. Lato DB (read-only) — su TEST38 si può correlare con le viste Oracle (es. USER_SOURCE per il corpo del package, V$SQL se si hanno i privilegi). Solo SELECT; mai eseguire procedure applicative in diagnosi (cfr. Troubleshooting). INFERRED

La modalità build DEBUG cambia la propagazione degli errori nel DAL: RequestDAL.vb racchiude l'esecuzione in Try … #If DEBUG Then Catch ex As Exception : Throw #End If … Finally cm.CloseIfNeeded(openResult). In DEBUG l'eccezione ha un punto di ri-lancio esplicito (comodo per il breakpoint "on throw"); in Release il Catch non è compilato e l'eccezione propaga comunque tramite Finally. VERIFIED (RequestDAL.vb:5078-5085).

6. Localizzare i log

  • Errori applicativi web (CASSANDRA): il catch di btnPost_Click chiama Cassandra.Errors.InfocadTraceWrapper.CreateError(appKey, ex, ServerApplicationName, msg) (makeTicket.ascx.vb:250), con msg che include USER e IDREQUEST. Questo è il punto di logging da cui partire per un fallimento di creazione ticket. VERIFIED
  • Log su sessione: LogTicketActionOnSession(_objRequest) (makeTicket.ascx.vb:236) registra l'azione (post-commit) sulla sessione. VERIFIED
  • Percorsi/destinazione dei file di log (rotazione, cartella su disco, LogManager): UNKNOWN — non determinati dalle fonti lette in questo batch. Non inventare percorsi.

7. Diagnosticare fallimenti di autorizzazione

Punto critico di sicurezza da tenere presente in debug:

  • Gate lato UI: l'accesso interattivo è filtrato da RequestCenterPage.Page_PreInit (redirect a DefaultUrl se non autenticato / non abilitato RequestCenter); la voce di menu "Requests" e il caricamento di makeTicket.ascx dipendono da questo gate. Il gate WCF equivalente è ExtraFlowActionsProxy via ValidateLoginKey. SUPPORTED (vedi FLOW-REQ-001).
  • Assenza di check nel BL: Request.Create e i metodi DAL non rieseguono controlli di autorizzazione. Di conseguenza un fallimento di autorizzazione si manifesta come redirect/blocco lato UI, non come eccezione nel BL. Questo è anche un rischio: gli entry-point condivisi (WCF/integrazioni) che chiamano lo stesso BL bypassano il gate UI. SUPPORTED (rischio TD-008; vedi TS-004 e Qualità e test).

Sintomo → dove guardare: "utente vede la pagina ma non dovrebbe" → Page_PreInit / abilitazione RequestCenterEnabled; "chiamata WCF crea un ticket che l'UI avrebbe rifiutato" → mancanza di re-check nel BL (TD-008).

8. Debug delle transazioni (Commit / Rollback)

L'unità di lavoro è RequestCenter.Transaction (RequestCenter/Transaction/Transaction.vb:3), che espone OpenConnection / Begin / Commit / Rollback / CloseConnection (:20,5,10,15,25) inoltrando a GlobalDataManager (BeginTransaction/CommitTransaction/ RollbackTransaction, GlobalDataManager.vb:155,171,181). VERIFIED

Sequenza tracciata (makeTicket): OpenConnection() (:111) → Begin() (:112) → … insert/ set/workflow … → Commit() (:216); su eccezione Catch → Rollback() (:240) + uplFilesPanel.GoRollBack(); Finally → CloseConnection() (:254). VERIFIED

Checklist di debug:

  • Eccezione prima del Commit → nessun ticket persistito (atteso). Verificare il log InfocadTraceWrapper.CreateError.
  • Ticket presente senza interfaccia workflow → vedi TS-003 (richiesta senza elemento DEM): correlare REQUESTWORKFLOWINTERFACE e ELEMENTWORKFLOWSTATE/HISTORY.
  • Workflow a singola attività → create-close automatico (comportamento atteso, non errore).

9. Debug dell'integrazione (WCF / .NET Remoting)

Lo stesso BL Request.Create è invocato anche da servizi WCF: RequestsReaderWCF.svc, RequestsCacheService.svc, ExtraFlowActionsProxy.svc. SUPPORTED (reverse trace in FLOW-REQ-001).

  • Per debuggare il path WCF: attach al processo host, breakpoint nel metodo .svc.vb corrispondente (es. RequestsReaderWCF.svc.vb) e in Request.Create (Request.vb:2222); confrontare col path interattivo.
  • Nel ramo WCF, GetConnectionManager risolve cm da OperationContext.Current (non da HttpContext): se cm è Nothing in debug, verificare quale ramo è attivo (Settings.vb:262+). VERIFIED
  • L'inventario SOAP/WCF completo è in API; il dominio è descritto in Service Desk.
  • .NET Remoting / TCP: InfocadServer/InfocadTester apre un client TCP (com.ClientConnect("TCP", "IPCServer"), InfocadTester/Start.vb) verso il tier servizi; utile come harness di attach per il debug del backend, ma non tocca il path RequestCenter web. SUPPORTED

10. Debug dei job in background

Il verticale RequestCenter non ha job in-process propri nel path di creazione: il lavoro schedulato per-cliente vive in progetti ServiceJob.<Customer> / TicketLoader<Customer> ospitati dai Windows Services. SUPPORTED (pattern di customizzazione — vedi Architettura). Il debug di un job segue il flusso §1 (attach all'eseguibile del servizio). Dettaglio dello scheduler (Quartz) e delle destinazioni: vedi Operations.

Riferimenti incrociati

Evidenze

  • FE code-behind: InfocadWeb/WebMachine/CASSANDRA/RequestCenterWeb/UserControls/FlowActions/makeTicket.ascx.vb:82 (btnPost_Click), :83 (CheckStateChange), :84-85 (validazione), :93 (GetCreationMoment/MakeProtocol), :111-112 (OpenConnection/Begin), :114 (Request.Create), :120-137 (Set/RequestMO), :185 (WriteDescription), :210 (_currentAct.Run), :214 (SetWorkflowInterface), :216 (Commit), :236 (LogTicketActionOnSession), :240 (Rollback), :250 (Cassandra.Errors.InfocadTraceWrapper.CreateError), :254 (CloseConnection).
  • BL: InfocadWeb/WebMachine/RequestCenter/Classes/Request.vb:25 (classe), :2222 (Create), :2342 (WriteDescription), :2596 (SetWorkflowInterface); interfaccia RequestCenter/Interfaces/TicketInterfaces.vb:39 (IRequestDAL).
  • DAL: InfocadWeb/WebMachine/RequestCenter.DAL.OracleODP/RequestDAL.vb:3-10 (guardia driver #If NET5_0_OR_GREATER), :5054 (addRequest→GESTREQUEST_T2.ADDREQUEST), :5078 (cm.ExecuteNonQuery), :5080 (OracleDecimal.ToInt32), :5081-5085 (#If DEBUG Catch/Throw + Finally CloseIfNeeded), :5407 (setDescription), :5641 (setWorkflowInterface).
  • Connection manager: InfocadWeb/WebMachine/RequestCenter/Configuration/Settings.vb:242 (GetConnectionManager), :244 (RCCONNECTIONMANAGER da HttpContext), :262+ (ramo WCF OperationContext).
  • Motore dati: InfocadWeb/WebMachine/DataManager/GlobalDataManager.vb:155,171,181 (Begin/Commit/RollbackTransaction), :214 (ExecuteNonQuery), :297 (ExecuteReader), :384 (ExecuteScalar), :423 (Fill).
  • Transazione: InfocadWeb/WebMachine/RequestCenter/Transaction/Transaction.vb:3,5,10,15,20,25.
  • Harness TCP backend: InfocadServer/InfocadTester/Start.vb (com.ClientConnect("TCP", "IPCServer")).
  • Test automatici: 0 framework rilevati nei progetti RequestCenter (grep xunit|NUnit|MSTest|VisualStudio.TestTools → vuoto). VERIFIED
  • Comandi Windows/IIS/msbuild/attach a w3wp.exe: NON verificati su questo host (macOS, no Oracle Client).