Table of Contents

InfocadServer

Il tier servizi/business della piattaforma. Contiene la logica applicativa di tutti i domini e l'accesso ai dati; gira come Windows Service, non sotto IIS. Non ha interfaccia utente.

Snapshot analizzato: commit 108881692678254c46391d24423548e22e217c0e (branch develop). Evidenza: TASK-SRV-001, docs/_generated/inventory-server.json.

Confini di responsabilità

Fa Non fa
Logica di business per dominio (Property, Booking, Energy, ECM, …) Rendering UI (sta in InfocadWeb)
Accesso a Oracle tramite stored procedure Definire lo schema DB (vive nel database)
Espone le BL come oggetti .NET Remoting Espone API REST o SOAP verso l'esterno (ApiController = 0; il SOAP è in InfocadWeb). L'unico WCF server-side è EnergyService; il 4° [ServiceContract] del repo è un proxy client generato verso Niagara (PropertyServiceIoT)
Job schedulati (Quartz.NET) e servizi di background Autenticare l'utente finale del web (lo fa il tier web, poi delega ai provider identity)
Riscrittura delle configurazioni al deploy (ConnectionsService) Personalizzazioni per-cliente (quasi tutte in InfocadWeb)

Come è organizzato: la slice verticale per dominio

È il concetto chiave del repository. Ogni dominio funzionale ripete la stessa sequenza di progetti; imparata una, sono tutte uguali (~20 domini).

flowchart LR
    SO["SharedObjects<br/>DTO / modelli"]
    IF["Interface<br/>contratti"]
    DAL["DAL<br/>stored procedure"]
    BL["BL<br/>logica"]
    CT["Controllers<br/>proxy Remoting"]
    CT --> BL --> DAL --> ORA[("Oracle")]
    IF -.-> CT
    IF -.-> BL
    SO -.-> BL
Progetto Ruolo Dove gira
<Dominio>SharedObjects DTO/entità serializzabili scambiate fra i tier entrambi
<Dominio>Interface interfacce (IDAO_*, I*BL): il contratto Remoting entrambi
<Dominio>DAL invoca le stored procedure Oracle (Execute*StoredProcedure) Windows Service
<Dominio>BL logica di dominio; classi MarshalByRefObject Windows Service
<Dominio>Controllers proxy: risolve l'oggetto remoto e inoltra la chiamata nel processo IIS del web
Important

I *Controllers sono compilati qui ma eseguiti nel tier web: sono la parte di InfocadServer che vive dentro IIS e apre il canale Remoting verso il Windows Service. È il punto in cui i due repository si toccano a runtime → Interazioni.

Varianti presenti oltre ai cinque layer canonici: Manager (12 progetti — in alcuni domini è il DAL reale, es. Report/Global), Service, Server. Non tutti i domini hanno tutti i layer: alcune BL sono gusci vuoti e la logica sta nel DAL/Manager (es. QualityCheck, Global) — dettaglio per dominio in Reference del codice.

Chi lo esegue (hosting)

Componente Tipo Nota
InfocadServer Windows Service (VB) servizio principale: host di 182 tipi remoti
ECMServer Windows Service (C#) documentale: 27 tipi remoti
IEMServer Windows Service (VB) IEM: 22 tipi remoti
ConnectionsService eseguibile riscrive le connection string nei *.exe.config al deploy
UpdateService, IEMService, WindowService eseguibili companion —
JobScheduler libreria scheduling Quartz.NET
EnergyService WCF sottile 3 [ServiceContract] (IDashBoardService, IDssDashBoardService, IPolicyRetriever), self-hosted (ServiceHost.Open()), 0 .svc
InfocadTester console harness manuale (non è una suite di test)

La composition root è InfocadServer/Business/Start.vb (+ StartECM.vb, StartIEM.vb): registra i canali Remoting e i tipi well-known. Vedi Operations.

Come parla con il resto del sistema

  1. Verso InfocadWeb — pubblica 137 DLL nella cartella condivisa Assembly/ e risponde su .NET Remoting (tcp o ipc).
  2. Verso Oracle — ODP.NET (Oracle.DataAccess unmanaged; Oracle.ManagedDataAccess nel nuovo codice) chiamando stored procedure: Execute*StoredProcedure in 238 file, ~2700 siti di chiamata. Nessun ORM; CommandType.StoredProcedure grezzo in 1 solo file.
  3. Verso l'esterno — praticamente nulla: le integrazioni stanno in InfocadWeb.

Dettaglio completo e configurazione: Interazioni tra i componenti.

Numeri (VERIFIED, conteggio meccanico)

  • 159 progetti (InfocadServer.sln: 193 entry = 34 solution folder + 159 progetti) — 83 C# / 76 VB.NET.
  • Stile: 155 classic MSBuild + 4 SDK-style. Target: v4.8 → 139, net8.0 → 19, net8.0-windows → 1 (20 progetti *XNET, 1:1 con la migrazione).
  • 8 progetti con OutputType Exe/WinExe; 137 con output in Assembly/.
  • Conteggi layer: Interface 27 · SharedObjects 26 · Controllers 23 · DAL 20 · BL 18 · Manager 12 · Service 5 · Server 3 · Altro 25 (host, tool, exporter).
  • Domini per numero di progetti: IEM 10 · Global 8 · Property 8 · BIM 8 · Energy 6 · ECM 6 · Booking 6 · poi Accounting / Check / Document / Maintenance / ServiceDesk / Stock / WorkerKit / Census / QualityCheck / Book / WorkAccounting / Project / Cde (5 ciascuno) · BulkLoader / Report / ExportService (4).

Build e vincoli

  • Completa: Windows + Visual Studio 2022 / msbuild + Oracle Client (ODP.NET unmanaged). nuget restore InfocadServer.sln (packages.config) → msbuild InfocadServer.sln.
  • Va compilato per primo: popola Assembly/, da cui dipende InfocadWeb.
  • Slice net8: dotnet build sui 20 progetti *XNET — compila anche su macOS/Linux (senza Oracle Client); ricollegano il sorgente legacy invece di duplicarlo.
  • Nessun test automatico, nessuna CI. Se serve "eseguire i test": non esistono.

Personalizzazione per-cliente

In questo repo c'è solo Plugin_SAPPM (VB). Tutti gli altri plug-in per-cliente (EntityLayer*, ServiceJob.*, TicketLoader*, ExternalAuth.*, ExternalDocSave.*) stanno in InfocadWeb.

Dove approfondire