!--a11y-->
XML-Namensräume 
Message-Instanzen müssen im Regelfall einem Namensraum zugeordnet sein. Im Integration Builder geben Sie diesen XML-Namensraum für (Fault-)Message-Typen an. In der Voreinstellung wird der Repository-Namensraum übernommen, in dem der (Fault-)Message-Typ angelegt wurde. In den folgenden Fall macht es Sinn, dass der XML-Namensraum vom Repository-Namensraum abweicht:
Zwei miteinander über XI kommunizierende Anwendungen liegen in der Regel in unterschiedlichen Software-Komponentenversionen, die nicht zwingend zusammen an Kunden ausgeliefert werden. Damit beim Kunden vollständige Definitionen von Message-Interfaces verfügbar sind, lässt der Integration Builder daher nur Verweise von Message-Interfaces auf (Fault‑)Message-Typen in der gleichen oder einer unterliegenden Software-Komponentenversion zu. Die beiden Anwendungen wollen oft die gleichen Message-Typen für die Kommunikation verwenden. Da kein Verweis möglich ist, kann sich die eine Anwendung einen Message-Typ der anderen Anwendung in ihren Repository-Namensraum kopieren (vorzugsweise mit allen abhängigen Objekten, siehe auch: Objekt kopieren). Wenn die Anwendungen für den Message-Typ und dessen Kopie dessen Repository-Namensraum als XML-Namensraum übernähme, wäre dies deren einziger Unterschied in der Message-Instanz und würde ein Mapping erfordern.
Über den XML-Namensraum können sich also zwei Anwendungen auf einen Namensraum für eine Message einigen. Der XML-Namensraum wird von der Proxy-Generierung übernommen und von der Proxy-Laufzeit in der Message-Instanz verwendet:
· Ein XML-Namensraum zu einem Message-Typ oder Fault-Message-Typ qualifiziert das Element-Tag für die Message.
· Ein XML-Namensraum zu einer Datentyp-Erweiterung qualifiziert die Felder innerhalb der Message-Instanz, die in der Erweiterung ergänzt wurden. Dadurch wird in ähnlicher Weise ein Mapping vermieden und Namenskonflikte bei einem Upgrade ausgeschlossen.
· In bestimmten Fällen ist ein XML-Namensraum für die Message-Instanz nicht erforderlich oder erwünscht. Sie können dann das Feld XML-Namensraum leer lassen.
Im folgenden konstruierten Beispiel wird zur besseren Lesbarkeit auf einen Unterscheidung zwischen Entwickler und Entwicklerin verzichtet.
...
1. In einer Anwendung von APO und CRM soll über eine Message ein Kundenauftrag vom APO in ein CRM-System geschickt werden. Innerhalb einer Software-Komponentenversion des CRM hat der verantwortliche CRM-Entwickler dazu einen Message-Typ SalesOrder im Integration Repository angelegt, der auf einen Datentyp verweist, der die Message-Struktur beschreibt.
2. Die APO-Anwendung auf Outbound-Seite benötigt den gleichen Message-Typ (und die entsprechenden Datentypen, auf die von dort verwiesen wird). Der verantwortliche APO-Entwickler kopiert dazu den Message-Typ in einen Repository-Namensraum der APO-Software-Komponentenversion und verwendet die Option Mit allen abhängigen Objekten. Dies bewirkt, dass der Message-Typ und alle Datentypen, die die Struktur der Message beschreiben, in die APO-Software-Komponentenversion kopiert wird.
3. Der APO-Entwickler einigt sich mit dem CRM-Entwickler darauf, für den Message-Typ SalesOrder den CRM-Namensraum zu verwenden. Er trägt daher im Feld XML-Namensraum der Kopie den Namensraum http://sap.com/CRM ein. Im Original-Message-Typ wurde dieser XMl-Namensraum automatisch vom Integration Builder gesetzt, weil er dem Repository-Namensraum zu SalesOrder im CRM entspricht.
4. Die Proxy-Laufzeit verwendet den XML-Namensraum in der Message-Instanz:
<ns1:SalesOrder
xmlns:ns1=„http://sap.com/CRM“>
<OrderHeader>
...
</OrderHeader>
<OrderItems>
...
</OrderItems>
</SalesOrder>
5. APO und CRM liefern Ihre gemeinsame Anwendung an einen Kunden aus. Der Message-Typ SalesOrder im Integration Builder ist folgendermaßen aufgebaut:


In diesem konstruierten Beispiel wurde das Suffix Type aus didaktischen Gründen an die Namen der Datentypen gehängt, um sie von den Wurzelelementen Address und OrderHeader abzugrenzen. Die Verwendung eines Suffix entspricht nicht dem Standard.
6. Der Kunde möchte den Datentyp Address um ein Attribut Airport und ein Feld State erweitern. Dazu geht er folgendermaßen vor:
a.
Er benötigt zwei
kundenspezifische Software-Komponentenversionen: Eine, die auf der
APO-Software-Komponentenversion basiert (beispielsweise CUST_APO) und eine
weitere, die auf der CRM-Software-Komponentenversion basiert (beispielsweise
CUST_CRM).
Software-Komponentenversionen und deren Abhängigkeiten definieren Sie im
System Landscape Directory (siehe auch:
Zusätzliche
Softwareabhängigkeiten definieren).
b. Der Kunde importiert seine Software-Komponentenversionen in den Integration Builder (siehe: Import von Software-Komponentenversionen). Dadurch sind auch die definierten Abhängigkeiten im Integration Builder bekannt.
c. Der Datentyp Address ist im zweiten Schritt kopiert worden. In den kundenspezifischen Software-Komponentenversionen CUST_APOund CUST_CRM ist Address unter Basis-Objekte sichtbar. Der Kunde muss nun sowohl in CUST_APOals auch in CUST_CRM eine Datentyp-Erweiterung anlegen, die jeweils auf den Datentyp Address der unterliegenden Software-Komponentenversion verweist.
7. Ähnlich wie in Schritt 3 vergibt der Kunde nun den gleichen XML-Namensraum http://customer.com/CRM/AddrExtension für die beiden Datentyp-Erweiterungen:
¡ Täte er dies nicht, müsste er nur auf Grund eines Unterschiedlichen XML-Namensraumes für die hinzugefügten Felder in der Message-Instanz ein Mapping definieren.
¡ Der XML-Namensraum vermeidet auch einen Namenskonflikt: Sollte SAP sich zu einem späteren Release dafür entscheiden, ein Feld mit dem gleichen Namen wie der Kunde in die Struktur mit aufzunehmen (zum Beispiel auf Anregung von Kunden), liegt dieser Name in einem anderen XML-Namensraum.
8. Zur Laufzeit werden die Felder, die der Kunde hinzugefügt hat, mit einem Qualifier zum Namensraum http://customer.com/CRM/AddrExtension versehen:
<ns1:SalesOrder
xmlns:ns1=”http://sap.com/CRM“
xmlns:ns2=”http://customer.com/CRM/AddrExtension“>
<OrderHeader>
<ShipTo>
<PartyId>1234</PartyId>
<Address ns2:Airport=„SFAirport“ >
<Name>Johnson</Name>
<Street>Lombard Street 10</Street>
<City>SanFrancisco</City>
<Country>US</Country>
<ns2:State>California</cus:State>
</Address>
</ShipTo>
</OrderHeader>
<OrderItems> ... </OrderItems>
</ns1:SalesOrder>