È possibile pubblicare i cataloghi direttamente da PARTproject, con diverse funzioni nel menu contestuale Gestione delle versioni [Versioning system] e 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).
Caricare le modifiche / eseguire la mappatura ERP:
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 .
Fare clic su 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.
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.
Aggiornare [Update table versions] il dialogo sulle versioni delle 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 . In caso di dubbio, confermare sempre con .
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.
La versione locale e corrente dell'utente viene salvata separatamente come nuova versione QA (nel ramo di pubblicazione del server SVN).
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.
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.
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.
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 .
Visibilità nei supporti di output
Le icone (
) indicano lo stato della pubblicazione. Se alcuni progetti pubblicati (directory) in i supporti di output sono visibili o non visibili, possono essere Comando del menu contestuale:
Sezione 6.10.3, “Marcatore di pubblicazione ”Per i dettagli vedere .
Lo stato di pubblicazione mostra la visibilità potenziale dei progetti. L'effettiva visibilità dei progetti nei media di output è determinata dall'interazione di diversi fattori. Sezione 6.10.4, “ Distinzione dei casi in merito alla visibilità del progetto nei media di output” Vedere .
Lo stato del marcatore di pubblicazione (impostato o rimosso) viene controllato in SVN quando viene eseguito il comando del menu contestuale Controlla nelle directory/progetti (rinuncia ai diritti di modifica) [Check in directories / projects (set read-only)], poiché l'informazione viene salvata nei rispettivi file di progetto.
Lo stato attuale della generazione e della pubblicazione può essere visualizzato in qualsiasi momento.
Sezione 6.10.7, “Dialoghi informativi: Messaggi... | Stato della pubblicazione | Cronologia della pubblicazione | File di registro ”Vedere .
L'e-mail di notifica contiene un file di log con le fasi dettagliate di generazione/pubblicazione.
Quando si genera/pubblica un catalogo, è necessario inserire le note di rilascio [Release Notes] che vengono visualizzate in PARTdataManager (menu contestuale del catalogo) e PARTadmin (categoria di aggiornamento del catalogo online, menu contestuale del catalogo).
Vedere la Sezione 5.9.21, “Pagina della scheda: Note di rilascio ”.