Integrazione nativa con Jira: Guida all'installazione
Importante da sapere prima della configurazione dell'integrazione di Jira
Prerequisiti per l'installazione
Per un test di base, abbiamo bisogno di conoscere le seguenti informazioni dal lato del cliente:
- Utente del servizio Jira e metodo di autenticazione scelto
- API REST di Jira URL
- Navigazione del server Jira URL (opzionale per i server Jira)
- Impostazione dei webhook
- Gli IP, le richieste API e le intestazioni di Targetprocess vengono aggiunti all'elenco dei permessi
Ciascuno di questi punti è descritto in dettaglio di seguito.
Servizio Jira Utente, autorizzazione, autenticazione
Autenticazione dell'utente del servizio Jira e del processo target
Per autorizzare tutte le azioni di Targetprocess in Jira. Il nome dell'utente apparirà nei registri e nella cronologia delle attività e sarà l'autore di tutte le modifiche in Jira, attivate dall'integrazione (aggiunta di commenti, modifica dello stato e altri campi).
Si consiglia di avere un utente del servizio dedicato all'integrazione di Targetprocess. Un utente dedicato evita problemi di connessione e interruzioni dell'integrazione quando Jira è configurato per richiedere CAPTCHA dopo diversi tentativi falliti di accesso. Se qualcun altro utilizza le stesse credenziali utente di Jira, il blocco di CAPTCHA può essere attivato e l'integrazione non sarà in grado di sincronizzare i dati a meno che CAPTCHA non venga risolto dall'utente.
Credenziali dell'utente del servizio Jira per l'autenticazione di Targetprocess
- L'accesso a Aggiungi/Modifica/Elimina per tutti i tipi di problemi, commenti, allegati e in tutti i progetti sarà sincronizzato con Targetprocess.
- gestire gli sprint" (se le Iterazioni del team saranno sincronizzate con gli Sprint di Jira)
- L'amministratore globale (con il permesso di richiedere "modifica flusso di lavoro") è necessario se il cliente richiede una mappatura automatica degli stati senza soluzione di continuità (se i nomi corrispondono, ma le transizioni no, l'utente dell'integrazione con il permesso di amministratore globale può calcolare le transizioni e applicare una qualsiasi delle opzioni disponibili)
- l'autorizzazione 'Modifica commenti' è necessaria se si richiede la sincronizzazione dei commenti (autorizzazione a modificare i commenti pubblicati da altri utenti di Jira).
Set di dati Jira per il test (progetto Jira per il pilota)
Ai fini della configurazione dell'integrazione e dei test, è necessario un accesso (UI) al progetto di test in Jira consentito per i test - aggiungere o modificare problemi, gestire gli sprint, sfogliare i problemi nel progetto, inviare commenti, allegati, ecc. O mappature POC reali dai PS
Ottenere URL a Jira Rest API
La navigazione in Jira Server URL (per gli utenti e l'accesso all'interfaccia utente) può essere diversa da Jira Rest API URL.
Per impostare il profilo di integrazione, è necessaria l'API URL. Se gli utenti di Jira lo consultano con un diverso URL, deve essere fornito nel profilo in modo che i collegamenti corretti ai problemi di Jira siano generati in Targetprocess.
Configurazione di Jira Webhooks
I webhook di Jira devono essere impostati per ogni profilo di integrazione. È necessaria l'assistenza dell'amministratore di Jira.
Di solito, l'amministratore di Jira dal lato del cliente ha accesso a questa parte della configurazione di Jira, quindi dobbiamo chiedere loro di aggiungere un webhook e aggiungerlo per ogni nuovo profilo. Le impostazioni dei webhook sono tutte nelle istruzioni del profilo (diverse per Server e Cloud in termini di Allegati)
Se si utilizzano instradamenti dinamici, potrebbe essere un'idea migliore aggiungere un filtro JQL a Jira ed escludere alcuni progetti se si sa che non si integreranno con Targetprocess. In caso contrario, tutti gli eventi dei progetti non integrati saranno trasmessi e apparirà un errore che indicherà che l'instradamento di destinazione non è stato trovato.
Tutti gli altri filtri JQL nel webhook devono essere evitati, Jira ha difetti comuni con le reazioni postali ad alcuni eventi quando si applicano i filtri.
L'integrazione non funziona se il webhook è impostato con il corpo escluso. Dobbiamo ricevere un JSON.
Ricordarsi di aggiornare i webhook in Jira, se l'account Targetprocess cambia URL.
Accessibilità a Jira per le richieste di Targetprocess
- Jira deve essere disponibile per le richieste API di Targetprocess.
- L'autorizzazione degli IP di Targetprocess può essere richiesta dal cliente. Il processo generale è il seguente:
- La gamma è disponibile su https://community.ibm.com/community/user/apptio/blogs/apptio-community-member/2023/01/16/targetprocess-public-ips-range?CommunityKey=55a3712d-1835-4ec2-bcd7-603e88cd9dd2
- Se un cliente non ha ancora accesso alla community, può richiederlo qui: https://community.apptio.com/home/request-community-access
- Un cliente autorizza l'intero intervallo IP. Gli IP singoli non vengono più forniti.
- Un cliente è iscritto a questa pagina (pulsante `Follow`)
- Quando l'IP sta per essere cambiato, il team di supporto modifica l'intervallo IP nella pagina della comunità
- I clienti abbonati ricevono una notifica e aggiungono anche questo nuovo IP
Funzioni a levetta
- Importazione iniziale da Jira. I commenti con il link a Targetprocess verranno aggiunti a ogni problema di Jira durante l'importazione, generando così molteplici notifiche via e-mail agli utenti di Jira. Considerate la possibilità di disattivare la funzione che aggiunge il collegamento all'entità Targetprocess come commento in Jira. Abilitarlo dopo l'importazione, se il collegamento dell'entità Targetprocess non sarà mappato al campo personalizzato di Jira.
WorkSharing:Linking:SkipComment
- La sincronizzazione delle operazioni di cancellazione è disattivata per impostazione predefinita su tutti i cluster. Tuttavia, se viene aggiunto un nuovo cluster privato per un cliente, assicurarsi che la sincronizzazione delle cancellazioni sia ancora disabilitata e che WorkSharing:DisableDeleteOppositeEntity sia attivato
WorkSharing:DisableDeleteOppositeEntity
- Alcuni campi non possono essere sincronizzati solo in un modo:
- Azioni come Elimina e Converti si sincronizzano in modo bidirezionale per impostazione predefinita quando la funzione WorkSharing:DisableDeleteOppositeEntity è disattivata. La sincronizzazione bidirezionale predefinita di Elimina o Converti può essere impostata in modo personalizzato con le regole di automazione. (Le regole si trovano in biblioteca. Nel febbraio 2023 i campioni saranno resi pubblici su dev.targetprocess.com )
- Le raccolte e le relazioni mappate e collegate si sincronizzano in modo bidirezionale e non è stato ancora possibile impostarle in modo unidirezionale. Ad esempio, le Epiche di Jira sono mappate sulle Caratteristiche, le Storie sulle Storie utente (collezioni figlio) e tutti gli altri tipi come relazioni regolari. Attualmente non è possibile limitare la direzione di sincronizzazione delle relazioni e sincronizzare solo le storie da Targetprocess e i bug solo da Jira. Le relazioni si sincronizzano in entrambi i sensi, i campi si sincronizzano nella direzione selezionata. Si tenga presente che gli instradamenti del progetto regolano la creazione di nuovi temi e non influiscono sulla sincronizzazione dei campi.
Associazioni
L'impostazione dell'integrazione è disponibile solo per gli amministratori di Targetprocess da Impostazioni > Integrazioni.
Ogni integrazione richiede un profilo di integrazione in cui sono definite tutte le regole di sincronizzazione. Un profilo può essere collegato a una singola istanza di Jira / ADO / Targetprocess.
- Un profilo può lavorare con una sola istanza di Jira.
- I dipartimenti (unità, team) sono indipendenti, i problemi di lavoro tra i dipartimenti non hanno relazioni tra loro e allo stesso tempo i flussi di lavoro sono molto diversi. Flussi di lavoro diversi significano mappature di tipi/campi diversi. Per facilitare la manutenzione della mappatura, dividere tali unità aziendali in profili separati.
Le relazioni tra profili non sono ancora supportate
Attivare con i toggle delle funzioni dalla pagina dell'infrastruttura.
WorkSharing:MultiSharing WorkSharing:Jira:SkipIntegrationUserEvents
Un'entità padre Targetprocess può essere condivisa tra più istanze di Jira con profili di integrazione diversi. Significa che tutte le proprietà, comprese le collezioni figlio, saranno condivise tra tutte le istanze. Per mantenere gli elementi figli nel loro Jira dedicato ed evitare l'auto-push a un'altra istanza di Jira, applicare i filtri nelle rotte per un tipo specifico di entità.
Non è possibile la condivisione multipla di un'entità all'interno di un profilo di integrazione.
L'invio in batch a Jira supporta solo un profilo, il primo abbinato.
Percorsi
Gli instradamenti non influiscono sulla sincronizzazione delle coppie esistenti, ma regolano la creazione iniziale di una coppia di problemi sincronizzati.
Se un problema è stato spinto su Jira per un progetto A e poi i percorsi sono stati aggiornati per escludere il progetto A da ulteriori sincronizzazioni, significa che non sarà possibile spingere/tirare problemi da/verso quel progetto. Ma gli elementi che sono stati spinti e collegati in precedenza procederanno alla sincronizzazione finché le mappature dei tipi e dei campi sono valide.
Percorsi statici
Gli instradamenti statici si riferiscono a casi semplici, quando il selettore dei progetti viene utilizzato nelle mappature e si mappano i progetti/le squadre di Targetprocess sui progetti di Jira.
Ogni instradamento statico ha dei filtri aggiuntivi. Con questi filtri si definiscono le condizioni che devono essere soddisfatte per sincronizzare i problemi da/verso Jira/Targetprocess.
Percorsi JS avanzati per la mappatura dinamica
Questo è un codice JS per impostare le condizioni delle mappature dell'ambito. Lo usiamo per casi complicati, quando il progetto di destinazione può essere diverso a seconda dei valori di alcuni campi. Biblioteca con esempi
Ad esempio:
- Targetprocess Portfolio Epic contiene un lavoro che crea un progetto separato in Jira, la mappatura non è da progetto a progetto, ma da Portfolio Epic a progetto Jira. Quindi aggiungiamo il CF 'Jira Project Key' a Portfolio Epic e calcoliamo il progetto Jira di destinazione per tutti gli elementi figli in base a questa abbreviazione in Portfolio Epic. Esempio.
- Il progetto in Targetprocess dipenderà dal valore del campo selezionato in Jira o viceversa - l'entità Targetprocess si sincronizza con il progetto Jira in base al campo personalizzato, selezionato a livello di genitore.
- Inoltre, qualsiasi serie sofisticata di filtri e condizioni aggiuntive, come ad esempio "tira le entità figlio se il loro progetto è uguale al progetto del loro genitore". Esempio.
Auto-push / Auto-pull
Entrambi i tipi di routing, statico e dinamico, dispongono di opzioni per l'estrazione o l'inserimento automatico delle schede.
Con l'auto-push abilitato, tutte le entità di Targetprocess saranno inviate a Jira non appena vengono aggiunte o modificate e superano il filtro nei percorsi. L'entità viene inviata a Jira come nuova.
Se si desidera collegare gli elementi di Targetprocess a problemi di Jira esistenti, è necessario disattivare l'estrazione automatica. Come soluzione è possibile scollegare l'entità Targetprocess dalla sua questione Jira e collegarla nuovamente a un'altra questione Jira. A meno che non venga aggiornato da qualche altro servizio o utente che attivi nuovamente l'auto-push.
Si consiglia di attivare l'auto-pull e di estrarre automaticamente i problemi di Jira se si desidera che tutti i problemi vengano sincronizzati immediatamente, non appena vengono aggiornati o creati e corrispondono ai filtri di sincronizzazione.
Non è possibile estrarre manualmente le schede da Jira, a parte l'importazione.
L'opzione Auto-pull è ora attivata per impostazione predefinita quando si creano nuovi percorsi. Questo miglioramento consente di risparmiare tempo e di ridurre il comportamento inatteso della sincronizzazione, poiché l'Auto-pull è essenziale per la maggior parte degli scenari di sincronizzazione di produzione.
Mappature dei tipi di entità
Qualsiasi entità di Targetprocess può essere mappata su un problema di Jira, compresa la gerarchia del dominio estendibile. Non supportiamo la sincronizzazione dei casi di test e l'area QA a causa dei molteplici livelli di annidamento nella gerarchia.
Se si mappa un tipo su più tipi diversi dall'altro lato, l'importazione iniziale considererà sempre il primo tipo di mappatura corrispondente. Nel caso in cui sia necessario selezionare un tipo specifico, è possibile utilizzare gli instradamenti JS in cui è possibile definire le condizioni per cui i valori dei campi personalizzati contrassegneranno uno specifico tipo di problema per l'importazione.
Se si elimina una mappatura di tipo in un profilo in esecuzione, tutti i problemi sincronizzati da quella mappatura saranno scollegati e la sincronizzazione cesserà.
Mappature dei campi
Alcuni campi sono supportati per impostazione predefinita. Se è necessario un comportamento personalizzato aggiuntivo, utilizzare le mappature JS. Ricordare che le mappature JS richiedono l'aggiunta di un comparatore personalizzato per essere considerate nei rapporti di convalida dei dati.
- Campi semplici come numero/testo a numero o testo, campi data, oggetto a testo saranno sincronizzati per impostazione predefinita.
- I selettori singoli e multipli si sincronizzano per impostazione predefinita se i loro valori corrispondono per nome. I selettori con opzioni diverse, non corrispondenti per nome, richiedono mappature JS. Vedere l'esempio di mappatura di Priority JS.
- Mappature degli Stati
- Per impostazione predefinita, gli Stati corrispondono al nome. Se i nomi non corrispondono, gli stati sono abbinati dal flag ‘isInitial’ o ‘isFinal’.
- Se i nomi corrispondono ma i flussi di lavoro e le transizioni consentite non supportano tale trasferimento, verranno richieste le transizioni possibili e applicate quelle più adatte, SE l'utente del servizio di integrazione ha l'autorizzazione di Global Admin. Senza l'autorizzazione dell'amministratore globale, la ricerca di possibili trasferimenti tra due stati selezionati non è possibile senza le mappature JS.
- Se i nomi non corrispondono, è necessaria una mappatura JS per gli stati
- Obiettivo-Processo Mappatura del team
- Per impostazione predefinita, il team assegnato si sincronizza per nome con una singola selezione in Jira
- Campo multi-selezione Team assegnato a Jira
- Componenti da team a Jira
- Mappatura dei componenti
- Componenti da multiselezionare in Targetprocess, mappatura bidirezionale con aggiunta automatica di nuovi componenti in Targetprocess;
- Time Tracking
- Importare i totali del tempo effettivo trascorso/mantenuto come un unico record temporale (vecchio dominio Tempo) a User Story, Bug o Task da Jira Issue Tempo totale trascorso/mantenuto
- Associazione utente
In caso di mappatura degli utenti di Jira sui campi utente di Targetprocess, l'integrazione creerà un nuovo utente di tipo integrazione.
Attivazione della funzione WorkSharing:UI:SyncProfile abilita la "risincronizzazione del profilo" completa. Si sconsiglia l'uso per i profili in esecuzione in produzione, in quanto trascina tutto da un lato all'altro e può provocare una perdita di dati. Si suggerisce di usarlo all'inizio dell'implementazione del conto e dell'aggiornamento intensivo delle mappature per estrarre i dati dei nuovi campi aggiunti all'ambito di sincronizzazione.
Importante.Tipo di utente integrato: gli utenti con la proprietà ‘isIntegration’ abilitata sono disponibili per tutte le operazioni come i normali utenti di Targetprocess: assegnare al lavoro, filtrare il lavoro per utenti, ecc. La differenza tra gli utenti normali e quelli di integrazione è che questi ultimi non possono accedere a Targetprocess. Gli utenti dell'integrazione vengono creati automaticamente dall'integrazione, quando viene soddisfatta l'email di un utente nelle assegnazioni e non viene trovata alcuna corrispondenza tra gli utenti TP esistenti. Gli utenti dell'integrazione possono essere aggiunti manualmente tramite richieste di post API o importazione CSV. La licenza conta gli utenti di integrazione separatamente dagli utenti regolari. Attualmente è possibile trovare un totale di utenti di integrazione solo nella sezione Account > Licenze.
Importante. Visibilità dell'e-mail in Jira Cloud: La mappatura predefinita degli utenti di Jira Cloud richiede la visibilità dell' email dell'utente di Jira. Con le e-mail non accessibili, utilizzare le mappature JS per mappare gli utenti in base all'account Jira memorizzato nel campo personalizzato ATP.
Jira Assignee è un campo a selezione singola. L'assegnazione del ruolo di Targetprocess è multipla. Per impostazione predefinita, quando si assegna a più di un utente un ruolo mappato in Targetprocess, ogni ultimo utente verrà sincronizzato con Jira Assignee. Quando si cambia l'assegnazione in Jira, vengono ripristinati tutti gli assegnati in Targetprocess, ma l'ultimo utente impostato da Jira.
- Campo personalizzato da utente a testo
Per impostazione predefinita, l'e-mail viene incollata nel campo di testo. Se avete bisogno del nome completo o di altri dettagli al posto dell'e-mail, aggiungete JS alla mappatura dei campi.
Campi non supportati. Mappature non consigliate
L'elenco verrà continuato non appena verranno scoperti nuovi campi non supportati.
- Aggiornamenti del campo Stima originale di Jira tramite trigger API e ricalcolo del tempo rimanente e del tempo trascorso in Jira. Pertanto, si sconsiglia di pubblicare direttamente su Jira Original Estimate.
- Sforzo. Il campo Effort è un campo calcolato in Targeprocess. Senza disabilitare il calcolo dell'impegno e ridefinirne il calcolo con la metrica, si aggiornerà regolarmente e automaticamente per far coincidere l'impegno completato con quello di ToDo. Pertanto, l'impegno potrebbe essere mappato solo a senso unico, per mostrare il totale in Jira. Ma non è consigliabile estrarre alcun numero da Jira nel campo Effort di Targetprocess. Per lavorare con gli sforzi, utilizzare i campi degli sforzi dei ruoli: sforzo del ruolo di sviluppatore o sforzo del proprietario della soluzione. In tal caso, lo sforzo verrà calcolato automaticamente e correttamente in base allo sforzo degli assegnatari responsabili.
- La data di creazione in Targetprocess non può essere mappata e impostata per i problemi estratti da Jira. Per prima cosa, l'integrazione crea un problema vuoto e poi applica i valori dei campi. La Data di creazione può essere applicata solo al momento della creazione, non successivamente. Tale modifica influirebbe sulle prestazioni, pertanto si suggerisce di mappare la data di creazione di Jira con il campo personalizzato Targetprocess date.
Iterazioni del team > Sprint di Jira
Esistono due modi diversi per sincronizzare gli sprint e il lavoro assegnato.
- La soluzione predefinita consigliata è quella di mappare e sincronizzare gli Sprint di Targetprocess Team come Sprint di Jira. Quando si collega l'iterazione del team a uno sprint esistente in Jira, o si spinge come nuovo, le date di inizio/fine, la descrizione e tutti gli elementi di lavoro mappati si sincronizzeranno da e verso Jira.Every. L'iterazione del team deve essere collegata agli sprint di Jira. Lo sprint di Jira deve essere collegato a una scheda. Per questo motivo, l'integrazione deve sapere in quali progetti e schede si possono creare nuovi sprint. Pertanto, è necessario mappare i team di Targetprocess nelle Board di Jira e tutti gli sprint del team appariranno in un progetto e in una board selezionati. Guida per l'utente finale su come spingere o collegare gli sprintNota:
Solo i progetti scrum Jira possono avere degli sprint, che saranno suggeriti nelle mappature Targetprocess Teams - Jira Boards. Il team non può essere mappato sulla scheda kanban e sul progetto.
L'utente dell'integrazione del servizio Jira deve disporre dell'autorizzazione "Manage Sprint" in Jira
Ogni nuova iterazione del team potrebbe essere inviata automaticamente a Jira con una regola di automazione aggiuntiva
- Qualsiasi mappatura JS per la sincronizzazione di Team Iteration come campo del problema sincronizzato. Nel caso in cui JS aggiorni il campo sprint delle entità Jira e Targetprocess senza sincronizzare le date e la descrizione dello sprint. Esempio di mappatura JS
La funzione di mappatura in blocco consente agli amministratori dell'integrazione di mappare centinaia di team a centinaia di schede Jira mediante l'importazione di un file CSV. Semplifica il processo di mappatura, facendo risparmiare tempo e riducendo gli errori.
Come amministratore dell'integrazione, se dovete mappare 500 team a 500 schede Jira, farlo manualmente comporterebbe 500 aggiornamenti individuali, che potrebbero richiedere diverse ore per essere completati. Tuttavia, utilizzando la funzione di mappatura in blocco, è possibile scaricare le mappature correnti, aggiornare il file CSV con le nuove mappature e quindi importare il file aggiornato. Questo processo consente di completare il lavoro in una frazione di tempo.
- Scaricate rapidamente la mappatura attuale di Teams e Jira Boards in un file in formato CSV.
- Estendete facilmente la mappatura aggiungendo nuove righe di ID dei team mappati agli ID delle schede di Jira.
- Importare il file CSV aggiornato per applicare la nuova mappatura.
- (Facoltativo) Scaricare l'elenco delle schede Jira disponibili per la mappatura.
- (Facoltativo) Scaricare l'elenco dei team Targetprocess.
- Scaricare la mappatura attuale di Squadre-Schede come file CSV.
- Estendere il file CSV squadre-schede con gli ID delle squadre e delle schede corrispondenti.
- Caricare il file aggiornato.
- Rivedere le selezioni e salvare le modifiche al profilo. Altrimenti, controllate la console del browser per maggiori dettagli se avete bisogno di rintracciare gli errori.
Rapporti
È possibile mappare e sincronizzare le relazioni tra due problemi di Jira in Targetprocess.
Se si naviga nella scheda Relazioni del profilo e si abbinano le relazioni, queste inizieranno a sincronizzarsi e appariranno nella scheda Relazioni in una vista entità.
Ad esempio, con la mappatura dei tipi come sotto e le relazioni come sopra, se Jira Epic ha un collegamento di tipo 'Blocks' a un Bug di Jira, ed entrambi i problemi di Jira si sincronizzano con Targetprocess come Feature e Bug in modo appropriato, allora la relazione 'Blocker' sarà aggiunta tra gli elementi di Targetprocess.
Qui si trovano le relazioni tra due problemi collegati ai problemi di Jira:
La relazione con il problema di Jira, il cui tipo è mappato nel profilo di integrazione, viene replicata nella vista Feature > scheda Relations.
Dettagli tecnici
Nella maggior parte delle situazioni, le viste delle entità saranno personalizzate automaticamente con la scheda "Lavoro sincronizzato" come impostazione predefinita. È l'ultima scheda della vista. L'ordine delle schede può essere modificato, se necessario, nelle impostazioni di "Viste dettagliate".
Se per qualche motivo il blocco "Lavoro sincronizzato" non è stato aggiunto automaticamente al termine della configurazione del profilo di integrazione, è possibile aggiungerlo manualmente
- Scheda
{ "title": { "type": "string", "value": "Synced Work", "localize": true }, "component": { "type": "work-sharing-v2/v2", "component": "WorkSharingInfoComponentV2", "componentId": "work-sharing-v2-some" }, "componentId": "section_si4pcbc" },
- Pannello laterale destro
{ "type": "work-sharing-v2/v2", "component": "WorkSharingInfoComponentV2", "componentId": "work_sharing_component" },
Se l'account ha la personalizzazione delle viste disattivata, il blocco 'Lavoro sincronizzato' viene visualizzato nel pannello di destra per Richiesta, Bug, Attività, Storia utente, Feature, Epic, Portfolio Epic e iterazione del team, senza tenere conto della mappatura dei tipi nel profilo.
Per tollerare più errori, l'integrazione crea prima un'entità vuota con il nome tecnico, come ad esempio:
creato dall'integrazione del livello di emissione ( 189997:10902:b523f50b-e2e1-40f6-be0f-3cf4798fc38a )"
Poi questo modello verrà riempito con i valori dei campi uno per uno, in base alle mappature. Quelli che non si candidano saranno saltati. Se si incontrano i nomi delle entità "create dall'integrazione del livello di emissione (ID)", significa che i valori dei campi non sono ancora stati applicati, parzialmente o per niente.
È possibile chiamare gli aggiornamenti pull/push per tale entità, se è collegata a un problema, per aggiornare i campi e controllare i log per gli errori di sincronizzazione effettivi. Se l'entità non è ancora collegata, può essere rimossa in modo sicuro.
???? In base a questa logica, la "Data di creazione" sarà uguale alla data di aggiunta del problema. Non è possibile modificare in seguito la data di creazione di un'entità Targetprocess esistente.
???? A causa di questa logica, i campi obbligatori di Jira ripristineranno i loro valori predefiniti con quelli di Targetprocess. Se i campi mappati in Targetprocess sono vuoti, il valore predefinito del campo Jira verrà rimosso subito dopo il trasferimento di tutti i valori dei campi e il completamento della creazione del problema.
Tempo medio di sincronizzazione
Le operazioni di sincronizzazione possono ritardare per diversi motivi (l'importazione di nuovi set di problemi è in corso, Jira limita l'accesso per un certo periodo di tempo o non è accessibile). Per sapere quanto tempo occorre per passare le modifiche tra due sistemi, si può fare riferimento a un tempo medio di aggiornamento. Il numero è approssimativo e vale soprattutto per i profili che lavorano costantemente. Il tempo medio di aggiornamento è calcolato in base agli ultimi 10 aggiornamenti. Per questo motivo, se l'ultimo aggiornamento è avvenuto ieri, si vedrà un orario valido per il carico di ieri.
Il tempo medio di aggiornamento si trova nell'elenco delle integrazioni per ogni profilo in esecuzione.
E anche nella vista entità, sotto i log:
Registri ed errori
Tutti i registri per l'integrazione del livello di problema si trovano in Impostazioni > Diagnostica e registri > Registri di servizio. Qui vengono mostrati i log più completi di tutti i profili di integrazione nativi.
I registri, filtrati per profilo, appaiono nel pannello inferiore all'interno di un profilo di integrazione sotto il link "Visualizza il registro dei messaggi".
Gli errori di sincronizzazione di entità specifiche e il registro appaiono nella vista dell'entità, nell'area "Lavoro sincronizzato" se si fa clic sul conteggio degli errori o sul link "Visualizza registro messaggi".
- Se la mappatura del tipo è stata eliminata mentre il profilo era disattivato o non accessibile. Ad esempio, sono stati collegati diversi problemi e poi sono state eliminate le mappature dei tipi corrispondenti dal profilo. La sincronizzazione verrà interrotta e la regola di sincronizzazione cancellata. In precedenza non venivano cancellate le regole, quindi i vecchi elementi potrebbero mostrare il seguente messaggio. Non si sincronizzerà più e l'entità dovrà essere ricollegata manualmente (unlink + link all'esistente o push).
Se poco dopo si aggiunge di nuovo al profilo esattamente la stessa mappatura dei tipi, questa coppia di elementi collegati non verrà fissata automaticamente: questa mappatura dei tipi verrà considerata come un'altra, con un altro ID. E tutti i problemi, collegati e sincronizzati in precedenza con la mappatura dei tipi eliminati, devono essere corretti manualmente - scollegati dal rapporto di sincronizzazione e spinti/collegati di nuovo.
- È possibile visualizzare il messaggio "Il problema collegato è stato eliminato" quando uno dei due problemi collegati è stato eliminato mentre il supporto per le azioni di cancellazione/conversione è disabilitato o il profilo di integrazione è stato disabilitato o Jira non era accessible.If Il problema di Jira è stato convertito o spostato in un altro progetto Jira e il suo KEY e/o il tipo di problema sono cambiati, quindi la coppia diventa non valida. Deve essere risolto manualmente: i problemi devono essere scollegati e spinti o collegati nuovamente ai problemi di Jira utilizzando le mappature corrette.
