Ein Mapping zwischen zwei Anwendungskomponenten darf nur kompatibel geändert werden. Sind inkompatible Änderungen nötig, müssen Sie ein neues Mapping anlegen. Diese Anforderung ist relativ leicht erfüllbar, wenn man davon ausgeht, das bei einer Message von einem Release zum nächsten nur optionale Elemente und Attribute hinzukommen können.

Ein Mapping ist basierend auf Messages von CRM 2.0 und APO 2.0 angelegt worden. Es laufen aber auch Message aus anderen Releases in das Mapping hinein beziehungsweise die erzeugte Message läuft in Zielsysteme unterschiedlicher Releases:

Im folgenden wird untersucht, wie man gewährleisten kann, dass das Mapping zu CRM 2.0 alle eingehenden Messages verarbeiten kann, ohne dass dies zu Kompatibilitätsproblemen in den verschiedenen Zielsystemen führt.

Da von CRM 1.0 nach CRM 2.0 nur optionale Elemente oder Attribute hinzugekommen sein können, hätte diese Message auch aus einem CRM 2.0 System kommen können, das eben gerade diese optionalen Felder weggelassen hat. Das Mapping sollte diese Message natürlich auch beherrschen. Dies ist gewährleistet, wenn

Die zusätzlichen Elemente/Attribute werden ignoriert. Dies ist gewährleistet, wenn das Mapping die Ausgangsfelder über explizite Pfadangaben (zum Beispiel "//OrderHeader/ShipTo" ) identifiziert anstatt Felder ‚abzuzählen‘. Verwenden Sie also beispielsweise keine der folgenden Methoden:

• Absolute Positionierung (etwa: "das 3. Element der 1. Unterstruktur")
• Miteinbeziehen der Häufigkeit des Auftretens von Feldern (etwa: "wenn in der Unterstruktur 10 Elemente sind, dann ...").

Die Proxies ignorieren zusätzliche Felder, daher entsteht kein Problem.

Es fehlen Felder, die von APO 2.0 nach APO 3.0 hinzugekommen sind. Da diese aber ohnehin nur optional sein dürfen, sollte dies kein Problem verursachen.