6.10.1. Panoramica del flusso di lavoro

È possibile pubblicare i cataloghi direttamente da PARTproject, con diverse funzioni nel menu contestuale Gestione delle versioni [Versioning system] e Pubblicazione [Publication].

Gestione delle versioni [Versioning system]

Figura 6.117.  Gestione delle versioni [Versioning system]

Pubblicazione [Publication]

Figura 6.118.  Pubblicazione [Publication]

La pubblicazione avviene in 3 fasi fondamentali: caricamento/mappatura delle modifiche, pubblicazione QA e pubblicazione live (la pubblicazione non deve necessariamente avvenire subito dopo il caricamento delle modifiche, ma occorre assicurarsi che la mappatura sia aggiornata prima della pubblicazione).

  1. Caricare le modifiche / eseguire la mappatura ERP:

    1. Controllare il [Check ERP-Mapping] dialogo di mappatura ERP [Check ERP-Mapping]:

      Non appena il comando Carica file modificati in directory/progetti sul server [Upload changed files in directories / projects to the server] viene eseguito dal menu contestuale Gestione versioni [Versioning system], la finestra di dialogo Verifica mappatura ERP [Check ERP-Mapping] si apre automaticamente (a condizione che 1. siano state apportate modifiche rilevanti ai dati e 2. l'opzione Verifica mappatura ERP durante il caricamento [Check ERP-Mapping on upload] sia attivata per il catalogo). Sezione 6.10.2.1.1, “ Controllare la mappatura ERP (Aggiungi mappatura ERP... e Modifica mappatura ERP...) [Modellazione catalogo].”Consultare anche le note all'inizio di .

      Controllare la mappatura ERP durante il caricamento [Check ERP-Mapping on upload]

      Figura 6.119.  Controllare la mappatura ERP durante il caricamento [Check ERP-Mapping on upload]

      Fare clic su Cerca [Search] per caricare gli stati del catalogo pubblicati e selezionare quello più recente. Attenzione: Soprattutto se la selezione Ricorda [Save selection] è attivata, è necessario cercare nuovamente uno stato del catalogo pubblicato (pubblicazione live) e selezionare quello più recente.

      Non selezionare lo stato salvato, ma effettuare una nuova ricerca.

      Figura 6.120. Non selezionare lo stato salvato, ma effettuare una nuova ricerca.

      Eseguire quindi la mappatura ERP per l'intero catalogo o per i progetti modificati. Il salto avrebbe senso solo in pochissimi casi, perché se appare questa finestra di dialogo, i file selezionati per il caricamento contengono almeno una modifica che richiede una nuova/aggiornata mappatura.

    2. Aggiornare [Update table versions] il dialogo sulle versioni delle tabelle [Update table versions]:

      Aggiorna versioni tabelle [Update table versions]

      Figura 6.121.  Aggiorna versioni tabelle [Update table versions]

      Questa finestra di dialogo viene visualizzata se i file delle schede/tac sono stati modificati (-> nuova versione della scheda), ma la modifica in sé non richiede una mappatura (ad esempio, una nuova riga aggiunta alla tabella).

      Il motivo è che le versioni delle schede nella mappatura devono essere aggiornate se la tabella corrispondente esiste già nella mappatura (corrente), in modo che non si verifichino problemi in seguito durante la pubblicazione live.

      Se sapete se la data visualizzata nel dialogo corrisponde all'ultima pubblicazione in tempo reale, confermate con , altrimenti fate clic su No. In caso di dubbio, confermare sempre con .

    3. Test opzionale

      Per verificare se qualcosa è stato dimenticato di verificare o se le versioni delle schede corrispondono allo stato locale, eseguire il comando del menu contestuale Aggiungi mappatura ERP [Add ERP mapping] in Pubblicazione [Publication] dopo l'aggiornamento del catalogo. Questo esegue la mappatura per lo stato attuale.

      Le mappature già verificate e già disponibili non vengono sovrascritte. Ciò significa che se ogni utente ha creato e verificato correttamente le proprie mappature, a questo punto non dovrebbe esserci più nulla da verificare manualmente. Solo se qualcosa è stato dimenticato o se le versioni delle schede non corrispondono allo stato locale, ci saranno ancora mappature con lo stato "da verificare [to check]" che devono essere verificate.

      Questo passaggio non è necessario, ma consente di determinare se ci sono problemi con la mappatura senza eseguire una pubblicazione live e di risolverli prima della pubblicazione.

  2. QA Publishing:

    La versione locale e corrente dell'utente viene salvata separatamente come nuova versione QA (nel ramo di pubblicazione del server SVN).

    [Importante]Importante
    • Lo stato sul server ("Trunk") NON viene utilizzato principalmente.

      Sezione 6.10.5, “ Generare lo stand QA... | Pubblicare lo stand dal vivo... ” Figura 6.274, “TRUNK del server SVN e BRANCH di pubblicazione del server SVN”Per i dettagli si veda , in particolare .

    • Se ci sono modifiche locali che non vengono caricate sul server (comando del menu contestuale Carica i file modificati nelle directory/progetti sul server [Upload changed files in directories / projects to the server] ), queste diventeranno comunque parte della pubblicazione QA per il motivo sopra indicato.

      -> Se l'utente che esegue una pubblicazione AQ aggiorna prima l'intero catalogo e non ha più modifiche locali che non sono state caricate, lo stato AQ diventa una copia dello stato attuale del server (trunk attuale). Questa è la procedura migliore nella maggior parte dei casi. Il file di mappatura disponibile al momento della pubblicazione QA è il file utilizzato successivamente per la pubblicazione live.

  3. Pubblicazione live: l'ultimo processo di pubblicazione QA effettuato viene trasferito come stato live, compreso il controllo della mappatura ERP, il trasferimento dei dati al portale live e la generazione del CIP.

    [Importante]Importante

    Non vengono trasferiti nuovi dati rispetto all'ultima pubblicazione AQ. Ciò significa che le modifiche apportate dall'ultima pubblicazione AQ non vengono prese in considerazione. (Se, ad esempio, si desidera che le modifiche facciano ancora parte della pubblicazione live, è necessario effettuare prima una nuova pubblicazione AQ).

Note sull'aggiornamento del file di mappatura

Se un utente ottiene i diritti di scrittura su una directory, automaticamente anche il file mapping.json aggiornato. Nel frattempo, un altro utente può partecipare a un altro e quando si caricano le modifiche, il File di mappatura adattato e caricato.

Il primo utente non ha più un file di mappatura corrente, ma questo non è un problema se i percorsi delle singole mappature non si sovrappongono. (E le sovrapposizioni non dovrebbero verificarsi, poiché gli utenti non possono ottenere l'autorizzazione di scrittura per la stessa directory).

È particolarmente importante che il file di mappatura corrisponda allo stato attuale (locale) al momento della pubblicazione dell'AQ (sarebbe problematico, ad esempio, avere il file di mappatura attuale a livello locale ma aggiornare solo alcuni degli altri file (ad esempio, le singole directory)).

Pertanto, se tutte le modifiche (comprese quelle apportate da altri utenti) devono essere pubblicate, è necessario aggiornare sempre prima l'intero catalogo, in modo da disporre di tutte le modifiche in locale.

Nota sulla pubblicazione parziale

Il processo di mappatura è lo stesso per la pubblicazione parziale, almeno se si crea la mappatura ogni volta che si effettua il check-in. Se si crea la mappatura una volta prima della pubblicazione, è necessario utilizzare il menu contestuale per eseguire il comando Aggiungi mappatura ERP per la pubblicazione parziale [Add ERP mapping for partial publication....]... sulla directory o sulle directory che devono essere pubblicate. Sezione 6.10.6, “Pubblicazione parziale ” Ulteriori dettagli sono disponibili su .

Ulteriori informazioni