Änderungsrichtlinie

ccppmop1592
Diese Änderungsrichtlinie beschreibt die Unterschiede zwischen
Classic PPM
-
Produktkonfigurationen
und -
anpassungen
und den jeweiligen Umfang des technischen Supports.
Diese Richtlinie gilt für alle aktiven Versionen von
Classic PPM
On-Premise und
Classic PPM
SaaS, einschließlich 15.x, 14.x, 13.x und älterer Versionen.
Konfigurationen
Konfigurationen
sind dokumentierte Funktionen, um das Verhalten des gelieferten Produkts zu ändern. Beispiele für dokumentierte Funktionen, die Sie für die Erstellung von Konfigurationen verwenden können, sind: Prozessabläufe, Studio-Portlets und XOG-Integrationen. Dokumentierte Funktionen werden von CA unterstützt, die zugehörigen Konfigurationen selbst jedoch nicht. Zum Beispiel wird die Studio-Funktion unterstützt, die zur Erstellung eines Diagramm-Portlets verwendet wird. Die Angaben des zugrunde liegenden NSQL-Codes, um Daten im Portlet einzugeben, werden jedoch nicht unterstützt. In diesen Situationen überprüft CA, ob die dokumentierten Funktionen nach der spezifischen Konfigurationsänderung erwartungsgemäß funktionieren. Allerdings wird CA für die Konfiguration selbst keine Fehlerbehebung durchführen. Zusätzlich zu NSQL werden folgende Konfigurationsänderungen nicht unterstützt: GEL-Skripte, Änderungen, die an Business Objects-Universen, Domänen oder Berichterstellungsattributen vorgenommen werden, und benutzerdefinierte XOG-Integrationen, die gegebenenfalls zu Leistungsproblemen führen können. CA arbeitet mit dem Kunden zusammen, um Probleme bei der Verwendung von dokumentierten Funktionen zu isolieren, um zu bestätigen, dass diese durch eine falsche Durchführung der Produktfunktionen verursacht wurden (und nicht durch falsch entworfene oder implementierte Konfigurationen).
Anpassungen
Anpassungen
sind die Verwendungen von nicht dokumentierten Mitteln, um das Produktverhalten zu ändern. Beispiele für Anpassungen sind Datenbankschemaergänzungen, Auslöser und Codeänderungen. Alle Codeanpassungen sollten mit dem Präfix "Z_" versehen werden, damit sowohl der Kunde als auch CA identifizieren können, wo Anpassungen im System vorhanden sind.
Kunden sollten beachten, dass die Konfigurationen von Version zu Version aktualisiert werden. Die Änderungen werden dabei nicht beeinträchtigt (sofern sie in der neuen Version noch gültig sind). Anpassungen werden jedoch nicht beibehalten. Anpassungen müssen auf aktualisierten Systemen mindestens erneut angewendet werden. In vielen Fällen müssen sie neu gestaltet und erneut implementiert werden, um mit den geänderten Produktfunktionen zu funktionieren. CA unterstützt ein angepasstes System und schließt dabei nur die Teile aus, die von den Anpassungen direkt betroffen sind. Der Support wird den Kunden häufig darum bitten, eine Anpassung aus diagnostischen Gründen zu entfernen, wenn die Anpassung möglicherweise eine Diagnose des Produktproblems verhindert. Kunden müssen diesen Anforderungen nachkommen, um Produkt-Support zu erhalten.
CA kann Anpassungen nach eigenem Ermessen prüfen und Alternativen empfehlen. In einigen Fällen kann der Support den Kunden darüber informieren, dass das System nicht unterstützt wird, wenn diese Anpassung verwendet wird. Anpassungen werden in Software-as-a-Service-Umgebungen (SaaS) von
Clarity
unter keinen Umständen akzeptiert.
Änderungsrichtlinien
Um das Risiko zu verringern, dass CA den Support für ein bestimmtes Problem ablehnt, das durch Änderungen verursacht wurde, befolgen Sie diese Richtlinien:
  • Fügen Sie keine Felder zu den standardmäßigen Datenbanktabellen hinzu. Erstellen Sie stattdessen neue Tabellen mit benutzerdefinierten Daten, die mit der standardmäßigen Tabelle verknüpft werden können.
  • Der direkte Zugriff auf standardmäßige Tabellen sollte schreibgeschützt sein. Um standardmäßige Tabellen zu aktualisieren, verwenden Sie die XOG-Funktionen.
  • Auslöser sollten bedingt ausgelöst werden, und die Bedingungen sollten ungewöhnlich sein. Auslöser sollten nur Standarddaten lesen. Sie sollten einfach geschrieben sein, um Deadlocks zu vermeiden. Auslöser sollten bei Upgrades deaktiviert werden.
  • Alle benutzerdefinierten Objekte sollten vor einem Produkt-Upgrade entfernt und anschließend wieder hinzugefügt werden.
  • Ändern Sie nicht den Quellcode, z. B. Java, XML, XSL, XBL, PMD und alle anderen Systemdateien, die im Lieferumfang des Produkts enthalten sind.