Table of Contents

BR-CDE — Regole di business del dominio Cde (connettore CDE esterno)

Regole di business del dominio Cde, estratte dal flusso pilota FLOW-CDE-001 (creazione di una cartella su CDE esterno) e dai sorgenti correlati. A differenza degli altri domini Infocad, Cde non è un dominio dati Oracle: è un connettore di integrazione documentale verso un Common Data Environment esterno (Autodesk ACC / Construction Cloud). La catena è CdeController → (.NET Remoting, endpoint Cde_BL.rem) → CdeBLBase → AccBL → HTTP REST verso un microservizio esterno (cdeUrl, assembly ACCDtoNetServ) che pilota Autodesk ACC (hub, project, folder, bucket S3, OAuth2 3-legged). Nessuna tabella, sequenza o stored procedure Oracle appartiene a questo dominio: il progetto CdeDAL è uno stub non implementato.

Sistema: Infocad (Descor)InfocadServer (Cde{Controllers,Interface,BL,DAL,SharedObjects}, C#)

  • InfocadWeb (BIMCenterWeb, C#, unico punto di consumo cablato dei metodi Cde). Trasporto interno .NET Remoting (nessun WCF/SOAP per questo dominio); trasporto esterno HTTP REST. Nessun ORM.

Le regole sono classificate per tipo, enforcement point (UI / BL / esterno / mixed) e confidence (VERIFIED / SUPPORTED / INFERRED). Gli identificatori tecnici NON sono tradotti.

Note di metodo e provenienza dell'evidenza

  • Evidenza di codice: percorsi relativi alla radice del repository Documentation/ (es. InfocadServer/CdeBL/CdeBLBase.cs:92). Tutta l'evidenza è inline in questa pagina.
  • Evidenza DB: assente per costruzione — verifica negativa. Il grep di Execute*StoredProcedure | OracleCommand | CommandType.StoredProcedure | OracleConnection | DataLayer. su InfocadServer/Cde* restituisce 0 occorrenze di codice attivo; il catalogo DB non contiene stored procedure di dominio CDE (l'unico match SEQ_BIM_CDE è una sequence del dominio BIM, non usata dal codice Cde). Vedi BR-CDE-002.
  • Dominio piccolo e prevalentemente comportamentale: poche regole, quasi tutte di configurazione, autenticazione e contratto di integrazione. Il percorso di scrittura è completo lato server ma privo di trigger UI cablato (BR-CDE-009).
  • Tipi usati: config-flag, integration (regole di connettore/contratto), permission, validation, state-transition (incl. gestione errori/ciclo di vita).

Registro delle regole (register)

id regola tipo enforcement conf
BR-CDE-001 Tecnologia CDE selezionata via cdeType: solo "Acc" è implementato; ogni altro valore ⇒ null/dizionario vuoto/"Not implemented" e nessuna chiamata esterna config-flag BL VERIFIED
BR-CDE-002 Nessuna persistenza Oracle: CdeDAL è uno stub, il BL usa direttamente HttpClient; tutti i dati risiedono sul CDE esterno integration BL VERIFIED
BR-CDE-003 Endpoint del microservizio CDE letto da AppSetting cdeUrl; HttpClient creato lazy se assente config-flag BL VERIFIED
BR-CDE-004 Autorizzazione delegata interamente al token OAuth2 3-legged Autodesk (refreshToken in query); scope data:read data:create data:write; nessun grant/tenancy Infocad lato Cde permission esterno/UI SUPPORTED
BR-CDE-005 Ciclo di vita token: persistito per-utente nel Setting CDESettings (BIM), ri-innescato se assente o scaduto (expires_in <= DateTime.Now) state-transition UI/BL VERIFIED
BR-CDE-006 Contratto di ritorno: Dictionary<string, OAUTH2TokenResponse> come envelope esito+token (dati nelle Keys, token rinnovato nelle Values) integration BL SUPPORTED
BR-CDE-007 Validazione minima in AccBL: hub/projectId (e folderId/code) obbligatori ⇒ ArgumentNullException; parametri restanti opzionali (aggiunti alla query solo se non null) validation BL VERIFIED
BR-CDE-008 Gestione errori: successo solo su HTTP 200; corpo null/status ≠ 200 ⇒ ApiException; CdeBLBase cattura ⇒ log + null; eccezioni: GetHubs ⇒ dizionario vuoto, UploadObject ⇒ re-throw state-transition BL VERIFIED
BR-CDE-009 Percorso di scrittura (CreateFolder/ModifyFolder/UploadObject/CompleteUpdateAsync) implementato end-to-end ma privo di trigger UI; "Nuova cartella" crea una directory su file system via BIMController.CreateDirectory integration UI SUPPORTED

Dettaglio delle regole

BR-CDE-001 — Selezione della tecnologia CDE via cdeType (solo "Acc")

  • Regola: ogni metodo di CdeBLBase esegue il ramo reale (istanzia AccBL e chiama il microservizio) solo se cdeType == "Acc". Per qualunque altro valore: i metodi che ritornano dizionari restituiscono null, GetHubs un dizionario vuoto, e i metodi che ritornano stringhe la costante "Error: Not implemented CDE Technology". In nessun caso "non-Acc" viene effettuata una chiamata esterna.
  • Tipo: config-flag · Enforcement: BL · Confidence: VERIFIED
  • Evidenza (BL): 13 guardie if (cdeType == "Acc") in InfocadServer/CdeBL/CdeBLBase.cs (es. CreateFolder :92-101, GetHubs :176-186, GetFolderContent :148-158); costante di fallback CdeBLBase.cs:129,335,393; rami else return null :73,101,157,215,243,279,307,364,421.
  • Evidenza (consumo): il valore "Acc" è cablato (stringa letterale) dal web in ogni chiamata — InfocadWeb/WebMachine/CASSANDRA/BIMCenterWeb/UserControls/BIMLoginCde.ascx.cs:837,933,1144,1192,1351.
  • customer_specific: false

BR-CDE-002 — Nessuna persistenza Oracle: dominio connettore verso CDE esterno

  • Regola: il dominio Cde non legge né scrive alcuna tabella o stored procedure Oracle. Ogni dato (hub, progetti, cartelle, item) risiede sul CDE esterno raggiunto via HTTP. Il progetto CdeDAL è uno stub: Cde_DAL implementa la sola GetName(int) → "Federico !" con la regione IConn vuota, e CdeDALFactory contiene solo metodi commentati (boilerplate copiato da Accounting). Il BL apre direttamente un HttpClient.
  • Tipo: integration · Enforcement: BL · Confidence: VERIFIED
  • Evidenza (stub DAL): InfocadServer/CdeDAL/OracleODP/Cde_DAL.cs:17-43 (metodo GetName :28-31, regione #region IConn vuota :33-40); factory commentata InfocadServer/CdeDAL/CdeDALFactory.cs:41-49.
  • Evidenza (assenza DB): grep negativo Execute*StoredProcedure|OracleCommand|CommandType.StoredProcedure|OracleConnection|DataLayer. su InfocadServer/Cde*0 hit di codice attivo; il BL istanzia new HttpClient() invece del DAL — CdeBLBase.cs:57,88.
  • customer_specific: false

BR-CDE-003 — Endpoint del microservizio CDE da configurazione (cdeUrl)

  • Regola: la base URL del connettore è letta dall'AppSetting cdeUrl. Se il costruttore di CdeBLBase riceve baseUrl == null, oppure se _httpClient non è ancora inizializzato, il BL legge ConfigurationManager.AppSettings["cdeUrl"] e istanzia un HttpClient prima di ogni chiamata. AccBL compone poi gli URL su quella base (BaseUrl.TrimEnd('/')).
  • Tipo: config-flag · Enforcement: BL · Confidence: VERIFIED
  • Evidenza (BL): costruttore CdeBLBase.cs:30-44 (fallback ad AppSetting :34); lazy-init ripetuto in ogni metodo CdeBLBase.cs:54-58,85-89 (pattern presente in tutti i 14 metodi); AccBL costruito con quella base CdeBLBase.cs:94; composizione URL AccBL.cs:324 (BaseUrl.TrimEnd('/') + path).
  • customer_specific: false

BR-CDE-004 — Autorizzazione delegata a OAuth2 3-legged (refreshToken); nessun grant Infocad

  • Regola: l'accesso alle risorse CDE è governato esclusivamente dal token OAuth2 3-legged di Autodesk. Il refreshToken è propagato come parametro di query in ogni chiamata REST; nessun controllo di autorizzazione, ruolo o tenancy Infocad viene applicato all'interno del dominio Cde. Gli scope richiesti al portale sono data:read data:create data:write. Il flusso è: redirect al portale Autodesk authentication/v2/authorize (response_type=code) → callback sul microservizio → Get3LToken(code) (POST /api/OAuth/oauth2/get3leggedToken/{code}).
  • Tipo: permission · Enforcement: esterno (portale Autodesk) + UI (avvio flusso) · Confidence: SUPPORTED (scope, redirect ed endpoint token VERIFIED; l'assenza di ulteriori grant Infocad è INFERRED dall'assenza di controlli nel codice del dominio)
  • Evidenza (UI/flusso): scope e redirect di autorizzazione BIMLoginCde.ascx.cs:1341,1378; client_id hard-coded "G1TmRPfyAODacCh2QuVzt2LptvnyC8OP" con GetClientID("Acc") commentata :1374; redirect_uri=https://localhost:7128/callback/ :1378.
  • Evidenza (token): AccBL.Get3LTokenPOST /api/OAuth/oauth2/get3leggedToken/{code} AccBL.cs:1389-1405; AccBL.ClientIdAsyncGET /api/OAuth/clientId AccBL.cs:1253-1264; refreshToken appeso in query in ogni metodo (es. CreateFolder AccBL.cs:335-338).
  • customer_specific: false (il client_id è però specifico dell'app Autodesk registrata; vedi Note e reperti)

BR-CDE-005 — Ciclo di vita del token: persistito per-utente in CDESettings, rinnovato a scadenza

  • Regola: il token OAuth2 (OAUTH2TokenResponse: access_token / refresh_token / expires_in) è persistito per-utente come Setting applicativo di chiave "CDESettings" (categoria BIM / Application), indicizzato dalla ProviderUserKey della sessione. Il flusso 3-legged viene ri-innescato quando il token è assente/vuoto o scaduto (refresh_token == "" || expires_in <= DateTime.Now); dopo il login FinishLogin("Acc") recupera il nuovo token, ri-salvato via RefreshCredential. La persistenza avviene nello store Settings (dominio BIM), non in tabelle Cde/Oracle (coerente con BR-CDE-002).
  • Tipo: state-transition · Enforcement: UI/BL (web) · Confidence: VERIFIED
  • Evidenza (UI): chiave/args del setting BIMLoginCde.ascx.cs:817, lettura GetSetting<OAUTH2TokenResponse> :821, condizione di scadenza/assenza :1336, avvio 3-legged AuthenticateOAUTH2(...) :1341, recupero token FinishLogin("Acc") :1351, salvataggio RefreshCredential(resp) :1353; refresh del credential dal risultato letto :840.
  • Evidenza (BL): recupero token già catturato dal microservizio via AccBL.IsArrivedAsyncGET /api/OAuth/token/isArrived AccBL.cs:1321-1332 (mappato da CdeBLBase.FinishLogin CdeBLBase.cs:346-372).
  • customer_specific: false

BR-CDE-006 — Contratto di ritorno: envelope Dictionary<string, OAUTH2TokenResponse>

  • Regola: i metodi-dati del connettore ritornano un Dictionary<string, OAUTH2TokenResponse> che funge da envelope esito+token: la chiave porta l'identificativo di risultato (es. l'hubId), il valore l'eventuale token rinnovato dal microservizio. Il chiamante estrae i dati dalle Keys e il token dalle Values, ri-persistendo quest'ultimo (vedi BR-CDE-005).
  • Tipo: integration · Enforcement: BL · Confidence: SUPPORTED (tipo di ritorno e uso lato UI VERIFIED; la semantica "key = dato, value = token" è dedotta dal consumo)
  • Evidenza (contratto): firme in InfocadServer/CdeInterface/IConn.cs:20-56 (dizionari) e :40-46 (metodi OAuth stringa/token); deserializzazione ReadObjectResponseAsync<IDictionary<string, OAUTH2TokenResponse>> AccBL.cs:374.
  • Evidenza (consumo): token → RefreshCredential(hubtest.Values.First()) BIMLoginCde.ascx.cs:840; dato → this.hubId = hubtest.Keys.First() BIMLoginCde.ascx.cs:852; controllo esito hubtest.Count() != 0 :838.
  • customer_specific: false

BR-CDE-007 — Validazione minima dei parametri lato AccBL

  • Regola: nel client REST AccBL i parametri identificativi obbligatori generano ArgumentNullException se null: projectId/hub per CreateFolder, hub/projectId/folderId per UploadObject, hub/projectId per ModifyFolder, code per Get3LToken. I parametri restanti (folder, parentFolderID, refreshToken, nameItem, hidden, ...) sono opzionali: vengono aggiunti alla query string solo se non null. Non è applicata alcuna altra validazione di formato o business.
  • Tipo: validation · Enforcement: BL · Confidence: VERIFIED
  • Evidenza (guardie): CreateFolder AccBL.cs:317-321; UploadObject AccBL.cs:912-919; ModifyFolder AccBL.cs:408-411; Get3LToken AccBL.cs:1391-1392.
  • Evidenza (opzionali condizionali): if (folder != null) ... if (parentFolderID != null) ... if (refreshToken != null) ...AccBL.cs:327-338 (CreateFolder), analogo :926-933 (UploadObject).
  • customer_specific: false

BR-CDE-008 — Gestione errori: ApiException, log + null, eccezioni per GetHubs/UploadObject

  • Regola: ogni chiamata REST considera successo solo lo status HTTP 200; un corpo null o uno status ≠ 200 sollevano ApiException (che espone StatusCode, Response troncato a 512 char, Headers). CdeBLBase racchiude ogni chiamata in try/catch: in errore logga su Descor.Infrastructure.LogManager.ExceptionLogger.LogException(ex) e ritorna null. Due eccezioni al pattern: GetHubs ritorna un dizionario vuoto (che l'UI interpreta come login/credenziali fallite → RefreshCredential(null) e uscita), e UploadObject ri-lancia l'eccezione (throw ex) anziché ritornare null.
  • Tipo: state-transition (error-handling) · Enforcement: BL · Confidence: VERIFIED
  • Evidenza (REST): successo solo su status_ == 200 altrimenti ApiExceptionAccBL.cs:372-385 (pattern replicato in tutti i metodi); definizione ApiException InfocadServer/CdeBL/ApiException.cs:9-29 (troncamento a 512 :18).
  • Evidenza (BL): catch + log + null CdeBLBase.cs:104-108 (pattern replicato); GetHubs dizionario vuoto in else/catch CdeBLBase.cs:185,191; interpretazione UI del vuoto come fallimento BIMLoginCde.ascx.cs:838-850; UploadObject re-throw CdeBLBase.cs:424-428.
  • customer_specific: false

BR-CDE-009 — Percorso di scrittura implementato ma privo di trigger UI; "Nuova cartella" usa il file system

  • Regola: le operazioni di scrittura verso il CDE — CreateFolder (PUT .../folder/create), ModifyFolder (PATCH .../folder/modify), UploadObject e CompleteUpdateAsync (POST .../object/upload/...) — sono implementate end-to-end lato server ma non hanno alcun chiamante UI/servizio cablato nei repository. Il consumo web attivo è di sola lettura (GetHubs, GetProjects, GetProject, GetFolderContent, FinishLogin). In particolare, il comando UI "Nuova cartella" dell'albero BIM crea una directory sul file system tramite BIMController.CreateDirectory, non Cde.CreateFolder.
  • Tipo: integration (reachability) · Enforcement: UI · Confidence: SUPPORTED (catena di scrittura VERIFIED sui sorgenti; l'assenza definitiva di un chiamante è INFERRED dai repo disponibili — potrebbe esistere in client non inclusi)
  • Evidenza (scrittura server): PUT create AccBL.cs:347-348; PATCH modify AccBL.cs:445-446; POST upload AccBL.cs:942-943; POST version/complete AccBL.cs:1052-1053; delega dal controller InfocadServer/CdeControllers/CdeController.cs:29-31 (CreateFolder) e :24-27 (CompleteUpdateAsync).
  • Evidenza (UI ≠ Cde): "Nuova cartella" → ctrlBIM.CreateDirectory(path) BIMLoginCde.ascx.cs:594-595; consumo web solo-read BIMLoginCde.ascx.cs:837,933,1144,1192,1351.
  • customer_specific: false

Note e reperti (per il team)

Rilievi di documentazione (codice non modificato), da confermare col team.

  • client_id OAuth hard-coded e GetClientID("Acc") commentataBIMLoginCde.ascx.cs:1374; il redirect_uri punta a https://localhost:7128/callback/ :1378. Configurazione da parametrizzare per ambienti non-dev (sospetto WIP/integrazione ACC non ancora rilasciata; correlato a BR-CDE-009).
  • cdeUrl non trovato in web.config/app.config nei percorsi ispezionati: l'endpoint del microservizio e l'host/porta del canale Remoting (SERVERADDRESS) restano da confermare in ambiente reale (BR-CDE-003).
  • RefreshToken(cdeType, refreshToken) è di fatto non implementata: il corpo "Acc" ritorna stringa vuota (chiamata al client commentata) — CdeBLBase.cs:326-336. Il rinnovo effettivo del token passa dall'envelope di ritorno (BR-CDE-006) e da FinishLogin/IsArrived (BR-CDE-005).
  • GetProjectsTest ritorna la costante "uvby" senza dispatch né chiamata esterna (CdeBLBase.cs:253-259): metodo di test residuo.
  • Concorrenza: i metodi risolvono i Task asincroni con .Result (chiamata sincrona bloccante) sopra un HttpClient — es. CdeBLBase.cs:96; nota di robustezza, non regola di business.