Show TOC Anfang des Inhaltsbereichs

Hintergrunddokumentation Kompatibilität von Änderungen  Dokument im Navigationsbaum lokalisieren

In den meisten Fällen wird angestrebt, dass Änderungen oder Erweiterungen eines Produkts kompatibel zur Vorgängerversion sind, das heißt: Verwendet ein Kunde ein Produkt, kann er ohne Probleme auf das neue Produkt umsteigen. Kurz gesagt sind inkompatible Änderungen solche, die den Programmcode der Vorgängerversion auf irgendeine Weise ungültig machen. Der Folgende Abschnitt soll einer Übersicht über kompatible Änderungen an Objekten der Exchange Infrastructure geben:

Interface-Objekte

Zur Kommunikation gibt es immer ein Outbound- und ein Inbound-Interface. Es muss also sichergestellt werden, dass eine Änderung einer der beiden Interfaces nicht zur Folge hat, dass der Counterpart ebenfalls modifiziert werden muss, damit die Kommunikation noch funktioniert. Es gibt folgende Optionen für kompatible Änderungen:

·        Hinzufügen von technisch und semantisch optionalen Attributen oder Elementen zu den referenzierten komplexen Datentypen. Semantisch optional bedeutet, dass ein Feld nicht doch von einem Empfänger erwartet wird, obwohl es als optional gekennzeichnet ist.

·        Kommunikationpartner können sich natürlich über Änderungen abstimmen. Hängt eine neue Version eines Produkts von Änderungen in einem anderen Produkt ab, muss der Kunde dann entsprechend darüber informiert werden (etwa „Das neue Produkt A, Version 2.0, benötigt wenigstens Produkt B, Version 3.5).

Generell sollten Sie darauf achten, bei inkompatiblen Änderungen eines Objekts zu überprüfen, ob es von anderen Objekten referenziert wird und die ‚Besitzer‘ dieser Objekte über die Änderung informieren (bisher gibt es allerdings noch keine Funktion für einen Verwendungsnachweis).

Mappings

Aus technischen Gründen darf ein Mapping zwischen zwei Anwendungskomponenten nur kompatibel geändert werden. Kompatibel heißt, dass das Mapping für eine beliebige Kombination von Nachfolgeversionen der beiden Anwendungskomponenten funktionieren muss. Einzige mögliche Änderungen an einem Mapping in verschiedenen Software-Komponentenversionen sind demnach Korrekturen. Sind inkompatible Änderungen nötig, müssen Sie also ein neues Mapping anlegen.

Beispiel

Ein Mapping zwischen den Anwendungskomponenten CRM 1.0 und APO 1.0 muss auch für folgende Kombination funktionieren: CRM 2.0 mit APO 2.0, CRM 1.0 mit APO 2.0 und CRM 2.0 mit APO 1.0 (siehe: Kompatibilität von Mappings sicherstellen).

Besteht ein Mapping aus mehreren Mapping-Programmen, die hintereinander ausgeführt werden, müssen die Mapping-Programme auch für jeden Zwischenschritt kompatibel bleiben.

Beispiel

Die Mapping-Programme M1 und M2 werden für folgendes Gesamt-Mapping verwendet: A (M1) B (M2) C. Für eine kompatible Änderung des Mappings reicht es nicht aus, wenn das Gesamt-Mapping von A nach C kompatibel ist. Es muss auch jeweils die Abbildung von A nach B und von B nach C kompatibel bleiben.

 

 

 

Ende des Inhaltsbereichs