gwusermanual:migration_to_4_7_x [GeowebFramework]

Questa pagina è in sola lettura. Puoi visualizzare il sorgente, ma non puoi modificarlo. Contatta l'amministratore se pensi che ci sia un errore.
====== Migrazione alla 4.7.X ======


===== Prerequisiti =====

==== Java ====
Java 8 o superiore.

==== Application Server ====
=== Tomcat ===
  - [[Tomcat 9|https://tomcat.apache.org/download-90.cgi]]
  - [[Tomcat 8.5|https://tomcat.apache.org/download-80.cgi]]
Non sono supportate versioni 10+, basate su **jakarta**
=== Wildfly ===
  - wildfly 20.0.1.Final [[wildfly|https://www.wildfly.org/downloads/]]

==== Database ====

=== Oracle ===
Geoweb 4.7.0 utilizza il driver oracle **ojdbc8 v 21.5.0.0**. 

In base alla matrice di compatibilità ufficiale, per utilizzare questa versione di Geoweb è necessario assicurarsi che la versione del database sia **'12.2 or 12cR2' o superiore**.

Matrice di compatibilità [[https://docs.oracle.com/en/database/oracle/oracle-database/19/jjdbc/JDBC-getting-started.html#GUID-926E5324-D89A-4A00-B1AE-975C1089F0EA|qui]]

=== Postgre ===
Geoweb 4.7.0 utilizza il driver **postgresql v 42.6.0**. In base alla matrice di compatibilità ufficiale, per utilizzare questa versione di Geoweb è necessario assicurarsi che la versione del database sia **"PostgreSQL 8.2 or newer"**.

Matrice di compatibilità [[https://jdbc.postgresql.org/download/|qui]].

=== MsSqlServer ===
Geoweb 4.7.0 utilizza il driver **mssql-jdbc v 12.2.0.jre8**.

In base alla matrice di compatibilità ufficiale, per utilizzare questa versione di Geoweb è necessario assicurarsi che la versione del database sia **SQL Server 2014**.

Matrice di compatibilità [[https://learn.microsoft.com/en-us/sql/connect/jdbc/microsoft-jdbc-driver-for-sql-server-support-matrix?view=sql-server-ver16|qui]]

==== MongoDB ====
La minima versione testata è **MongoDB 4.2**.
In caso contrario l'applicativo segnalerà un errore del tipo:
<code>
....ERROR .... - Server at 127.0.0.1:27017 reports wire version 4, but this version of the driver requires at least 6 (MongoDB 3.6).
</code>

==== Alfresco ====

I vecchi componenti CMIS continuano a lavorare, come prima, con **Alfresco 5**.
I nuovi componenti CMS, necessitano di **Alfresco 7**.

==== SharePoint ====


===== Migrazione sdf da Layout a Drawing =====

Il passaggio di Geowebframework dalla versione 4.6 alla 4.7 porta con sé grandi cambiamenti per quanto riguarda la visualizzazione delle planimetrie. Lo sfondo, o sdf, non sarà più collegato all’intero layout ma semplicemente al drawing, cioè non sarà più visualizzato un unico sfondo che fa riferimento a tutti i drawing che sono presenti nel layout (o piano) selezionato, ma saranno visualizzati tanti sfondi sovrapposti quanti sono i drawing.

==== Modifica Modello Dati ====
La modifica al modello dati consiste nello spostamento della colonna SDF dalla tabella gwd_layout alla tabella gwd_drawing. Si trovano gli script di migrazione nella cartella apposita S:\Rilasci GW4\4.7\script migrazione da 4.6.X

==== Caricamento Planimetrie ====
Il caso d’uso di caricamento di una planimetria da Upload Manager o da Client Cad non cambia per l’utente finale. I cambiamenti ci sono solamente nei processi lato server. L’sdf non dovrà essere più aggiornato all’interno della tabella gwd_layout, ma dovrà andare a lavorare sulla gwd_drawing.
A livello tecnologico questo comporterà una velocizzazione della procedura di inserimento SDF nel database in quanto la procedura più onerosa (cancellazione degli oggetti dall’SDF) sarà bypassata poiché ad ogni caricamento l’sdf sul drawing sarà ricreato da zero.

==== Visualizzazione Planimetrie e Mapguide ====
La visualizzazione delle planimetrie sarà il ramo che subirà il cambiamento più grande. Fino a questo momento la visualizzazione di una planimetria era effettuata per layout (o piani) e al suo interno erano rappresentati più drawing facenti parte di unità tecnologiche differenti. Il caso d’uso deve rimanere uguale a livello funzionale.
Questo è possibile poiché all’interno di Mapguide Maestro è configurato un datasource fittizio chiamato SDF che è usata come fonte dati per tutti i layer di sfondo. Questo datasource viene sostituito dinamicamente in fase di apertura della mappa con l’sdf che viene preso dal record della tabella gwd_layout corrispondente.
La modifica alle tabelle presentate precedentemente va ad inficiare pesantemente a questa logica:
 
•	Su mapguide Maestro andranno creati tanti SDF quanti sono i drawingType (regole di caricamento, divise per unità tecnologiche) all’interno del prodotto
•	I layer di sfondo andranno divisi e identificati all’interno di uno dei datasource creati nel punto precedente
•	A questo in fase di apertura della mappa (metodo setBackgroundFilter in MapguideService.java) saranno creati tanti dinamicamente tanti datasource quanti sono i drawingType facenti parte di quel layout (piano) selezionato.
•	La logica con cui viene generata la legenda laterale non sarà modificata, a meno che non si ricada nel caso che andremo a trattare a breve
=== Caso Limite ===
Il caso limite che andrà particolarmente attenzionato è il caso in cui si ha un layout al cui interno sono presenti più drawing di cui almeno due fanno parte dello stesso drawingType.
A questo punto devono essere creati dinamicamente due datasource analoghi che fanno riferimento allo stesso datasource fittizio. I layer che fanno riferimento a questo datasource di conseguenza dovranno essere individuati e duplicati.
Nella legenda laterale dovranno essere raggruppati in cartelle i layer che fanno riferimento a questo drawingType
==== Riconciliazione Dati Esistenti ====
A partire dalla versione 4.7.0 deve essere spostato il blob sdf dalla tabella gwd_layout alla gwd_drawing. Per fare questo deve essere eseguita una riconciliazione chiamando il metodo upgradeSDFToGwdDrawing direttamente dal browser. Ad esempio andando a scrivere nell’url del browser, ad esempio:

http://prm.svil.gwcloud.it/spm/upgradeSDFToGwdDrawing

L’operazione di riconciliazione è semplice nel caso in cui ogni layout abbia un solo drawing al suo interno, mentre è più lunga e complicata nel caso di più drawing all’ìnterno del layout: il metodo dovrà andare a splittare ogni sdf in base al pk_drawing di ogni geometria al suo interno e andare a formare tanti sdf diversi quanti sono i drawing all’interno del layout, impiegando fino ad alcuni minuti nel caso di sdf particolarmente complessi