Criteri di modifica

ccppmop1591
Questo articolo relativo ai criteri di modifica descrive le differenze tra le
configurazioni
e le
personalizzazioni
di prodotto di
Classic PPM
e il relativo ambito del supporto tecnico.
Questi criteri sono validi per tutte le versioni attive della
Classic PPM
On-premise e della
Classic PPM
SaaS, incluse le release 15.x, 14.x, 13.x e precedenti.
Configurazioni
Le
configurazioni
sono funzionalità documentate utilizzate per modificare il comportamento del prodotto fornito. I flussi di processo, le portlet Studio e le integrazioni basate su XOG rappresentano esempi di funzionalità documentate che è possibile utilizzare per creare configurazioni. CA supporta le funzionalità documentate ma non le configurazioni correlate. Ad esempio, viene supportata la funzionalità Studio che consente di creare una portlet di grafico, ma non le indicazioni del codice NSQL sottostante utilizzato per fornire i dati alla portlet. In queste situazioni, considerata la specifica modifica della configurazione, CA verificherà che le funzionalità documentate siano in funzione come previsto, ma non risolverà i problemi legati alla configurazione stessa. Oltre a NSQL, altri esempi di modifiche della configurazione non supportate sono gli script GEL, le modifiche apportate agli universi Business Objects, i domini, gli attributi di reporting e le integrazioni personalizzate di XOG che potrebbero causare problemi nelle prestazioni. CA lavorerà con il cliente per isolare i problemi riscontrati durante l'utilizzo di funzionalità documentate al fine di confermare che sono il risultato dell'esecuzione non corretta di funzionalità di prodotto (e di configurazioni progettate o implementate in modo errato).
Personalizzazioni
Le
personalizzazioni
consistono nell'utilizzo di mezzi non documentati per modificare il comportamento del prodotto. Le aggiunte allo schema di database, le attivazioni e le modifiche del codice sono esempi di personalizzazioni. Tutte le personalizzazioni del codice devono essere precedute da Z_ per consentire al cliente e a CA di identificare le personalizzazioni esistenti nel sistema.
Il cliente deve tenere presente che le configurazioni verranno aggiornate da una versione all'altra con le modifiche intatte (nella misura in cui esse siano ancora valide nella nuova versione), a differenza delle personalizzazioni. Le personalizzazioni devono essere applicate nuovamente ai sistemi aggiornati e, in molti casi, potrebbe essere necessario progettarle e implementarle nuovamente per garantirne il corretto funzionamento con le funzionalità di prodotto modificate. CA offrirà il supporto per i sistemi personalizzati, ad eccezione soltanto delle parti direttamente interessate dalle personalizzazioni. Il Supporto tecnico di solito chiede al cliente di rimuovere una personalizzazione per motivi di diagnostica poiché questa potrebbe contribuire al problema diagnosticato o impedire di rilevarlo. Il cliente è tenuto rispettare questa richiesta per ricevere il supporto per il prodotto.
A propria discrezione CA potrà rivedere le personalizzazioni e consigliare alternative. In alcuni casi il Supporto tecnico può informare il cliente che non supporterà il sistema in caso di utilizzo di tale personalizzazione. Le personalizzazioni non sono accettate in nessuna circostanza negli ambienti Software-as-a-Service (SaaS, precedentemente noto come On Demand) di
Clarity
.
Linee guida sulle modifiche
Per ridurre il rischio che CA impedisca il supporto per un problema particolare causato da modifiche, attenersi alle indicazioni seguenti:
  • Non aggiungere campi alle tabelle di database predefinite. Al contrario, creare nuove tabelle per contenere i dati personalizzati che possono essere unite con la tabella predefinita.
  • L'accesso diretto alle tabelle predefinite deve essere di sola lettura. Per aggiornare le tabelle predefinite, utilizzare le funzioni XOG.
  • I trigger devono attivarsi in via condizionale e le condizioni devono essere rare. I trigger dovranno leggere solo i dati predefiniti. Dovranno essere semplici e scritti per evitare blocchi critici. I trigger devono essere disabilitati durante gli aggiornamenti.
  • Tutti gli oggetti di database personalizzati devono essere rimossi prima dell'aggiornamento del prodotto e quindi aggiunti nuovamente in seguito.
  • Non modificare il codice sorgente, inclusi Java, XML, XSL, XBL, PMD e tutti gli altri file di sistema forniti con il prodotto.