XML Namespaces (SAP Library - Enterprise Services Repository)

XML Namespaces

Use

XML namespaces are important for exchanging messages.

Message instances must normally be assigned to a namespace. In the ES Builder, specify this XML namespace for (fault) message types. In the default setting, it is the repository namespace in which the (fault) message type was created that is transferred. In the following instance, it is recommended that the XML namespace is different to the repository namespace:

Two applications that communicate are usually located in different software component versions, which are not necessarily shipped to customers. To ensure that the customer does not receive incomplete service interface definitions, the ES Builder only permits references from service interface operations to (fault) message types in the same software component version or a sub-software component version. Both applications often want to use the same message types for communication. Since references are not possible, one of the applications can instead copy a message type from the other application to its repository namespace (preferably including all dependent objects, see also: Copying Objects). If the application were to use its repository namespace as the XML namespace for the message type and its copy, this would be the only difference in the message instance and would require a mapping.

The XML namespace therefore enables two applications to agree on a namespace for a message. Proxy generation applies the XML namespace and proxy runtime uses it in the message instance:

· An XML namespace for a message type or fault message type qualifies the element tag for the message.

· An XML namespace for a data type enhancement qualifies the fields within the message instance, which are enhanced in the enhancement. In a similar way, this avoids a mapping and excludes naming conflicts during an upgrade.

· In certain cases, you may not need to or want to use an XML namespace for the message instance. In that case you can leave the XML Namespace field empty.

Example

An XML Namespace for Message Types

...

1. In a joint APO/CRM application, a customer sales order is to be sent from APO to a CRM system by using a message. A CRM developer has created the message type SalesOrder within a software component version of CRM in the ES Repository. The message type references a data type that describes the message structure.

2. The APO application on the outbound side requires the same message type (and the corresponding data types that are referenced from there). The APO developer then copies the message type to a repository namespace in the APO software component version and uses the option With All Dependent Objects. The message type and all data types that describe the structure of the message are copied to the APO software component version.

3. The APO developer agrees with the CRM developer to use the CRM namespace for the SalesOrder message type. Therefore, the APO developer enters the copy of the namespace http://sap.com/CRM in the XML namespace field. This XML namespace is automatically set in the original message type by the ES Builder, because it corresponds to the repository namespace for SalesOrder in CRM.

4. Proxy runtime uses the XML namespace in the message instance:

<ns1:SalesOrder
xmlns:ns1=“http://sap.com/CRM“>

An XML Namespace for Data Type Enhancements

5. APO and CRM ship their joint application to a customer. The message type SalesOrder is structured as follows in the ES Builder:

This graphic is explained in the accompanying text

Note

In this imaginary example, the suffix Type is added to the data type name to help distinguish it from the root elements Address and OrderHeader. Suffixes do not have to be used otherwise.

6. The customer wants to enhance the data type Address with the attribute Airport and a field State. To do so, he proceeds as follows:

a. He requires two customer-specific software component versions: One which is based on the APO software component version (for example, CUST_APO) and another that is based on the CRM software component version (for example, CUST_CRM). You define software component versions and their dependencies in the System Landscape Directory (see also: Defining Additional Software Dependencies).

b. The customer imports his software component versions to the ES Builder (see: Importing Software Component Versions). This means that the defined dependencies are also known in the Integration Builder.

c. The data type Address is copied in the second step. Address is displayed under Basis Objects in the customer-specific software component versions CUST_APO and CUST_CRM. The customer must now create a data type enhancement in both CUST_APO and CUST_CRM. Both enhancements must reference the data type Address in the underlying software component version.

7. Similar to step 3, the customer must now give both data type enhancements the same XML namespace http://customer.com/CRM/AddrExtension:

¡ If he does not, he will have to define a mapping for the additional fields in the message instance as a result of a differing XML namespace.

¡ The XML namespace also helps to avoid naming conflicts: If SAP were to decide in a later release to include a field in the structure that has the same name as the name used by the customer (for example, following a customer request), then this name will be in another XML namespace.

8. At runtime, the fields that the customer has added are given a qualifier for the namespace http://customer.com/CRM/AddrExtension:

<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>