| Description | Query Code Lists |
| Name | QueryCodeListIn |
| Namespace | http://sap.com/xi/Common/DataTypes |
| Process Component Description | Metadata Repository Management |
| Process Component Name | MetadataRepositoryManagement |
| Process Component Namespace | http://sap.com/xi/Metamodel |
| Deployment Unit Description | Basis |
| Endpoint Activation | By Scoping of Process Component | Operations |
| Release Status | Released |
An interface to query code list data. Code lists provided by partners are also supported.
The web service interface Query Code List In enables you to connect external applications to your on-demand system and to query and read code lists in your system. The web service interface Query Code List In is relevant if your company wants to access and manage all kinds of objects, dealing with code lists, from external applications.
The web service interface Query Code List In offers the operation Find Code List By ID.
Here is an example of a simple web service request:
Show full documentation
Show full documentation
<n0:CodeListByIDQuery_sync xmlns:n0="http://sap.com/xi/SAPGlobal20/Global">
<CodeListSelectionByID>
<SelectionByCodeDataType>
<Name>RegionCode</Name>
<NamespaceURI>http://sap.com/xi/AP/Common/GDT</NamespaceURI>
</SelectionByCodeDataType>
<SelectionByLanguageCode>EN</SelectionByLanguageCode>
<SelectionByContext>
<Parameter>
<Name>CountryCode</Name>
<Value>DE</Value>
</Parameter>
</SelectionByContext>
</CodeListSelectionByID>
</n0:CodeListByIDQuery_sync>
There are no prerequisites.
Query operations are mass-enabled stateless synchronous web service operations. Transferring or requesting amounts of data that are too large causes communication timeouts. The web service consumer (external application) is responsible for ensuring reasonable sizes for mass operations.
The structure of the query response message consists of two parts:
A business document specific part containing the returned business documents
Log items containing system messages including errors, warnings, and information messages raised by the system during processing of the web service request.
Many external applications consuming web services have special requirements and restrictions regarding the format of WSDLs. Some external applications require service definition WSDLs describing the web service signature. This is normally sufficient for the creation of static client-side proxies. Other external applications, normally those that do not create static client-side proxies, require binding WSDLs including the endpoint definition and authentication policy information.
In both cases, it may be the case that the external application imposes special restrictions on the structure or the size of WSDLs.
Microsoft InfoPath requires binding WSDLs and considers elements with the attribute "minOccurs=0" as "mandatory". However "minOccurs=0" means "optional" in SAP web services. In order to circumvent this problem, the WSDL must be saved locally and an additional attribute "nillable=true" must be added to make a query parameter optional for Microsoft InfoPath.
For very small clients such as mobile devices, the size of the WSDL itself may become a problem. In most cases the client only requires a very small part of the signature, but due to the complexity of the WSDL they may end up with long runtimes during serialization of the request or deserialization of the response. In order to circumvent this problem, the WSDL must be saved locally and the optional parts of the signature have to be removed before the WSDL is imported or static client-side proxies are generated.
External applications have to take into account that web service request and response message types can be enhanced with additional elements and attributes. Enhancements can be created by SAP, SAP partners, and administrators. Enhancements of request message types are always optional elements or attributes. The SAP system does not require the external application to provide values in the request. Enhancements of response message types can contain mandatory elements or attributes. The external application must be able to process the extended response successfully.
XML element and attribute names are always stable. Technical definitions of data types can be enhanced in a compatible way. This may result in changed data type names. External applications can rely on XML element names and attribute names, but should not rely on data type names.
You can find general information about Web services, their structure and consumption in the Web Services documentation.
| Description | Find code lists |
| Name | FindCodeListByID |
| Synchronous | yes |
| Release Status | Released |
To query code list data by ID.
The request message of the operation FindCodeListByID contains the CodeListSelectionByID node that groups all possible selection parameters.
This node groups all selection parameters. The selection parameters are:
| Selection Parameter | Remark |
|---|---|
| SelectionByCodeDataType | Selection by code data type. The structured segment contains the mandatory elements Name and NamespaceURI, which identifiy the code data type. The corresponding values can be looked up in the WSDL of the service interface, which should be executed with code values. |
| SelectionByLanguageCode | Selection by language code. This element is optional and can be omitted if code value descriptions should be returned in the logon language. Otherwise you can specify a concrete language, for example, EN for English, to return all code value descriptions in English. |
| SelectionByContext | Selection by context. This segment is optional and can be filled in case of context specific code lists. Context specific code lists contain code values that are only unique within the same context. For example, the region code value 01 is not sufficient to identify a specific region in the world. Additionally the country information is needed to make a precise statement about the specific region. For example, region code value 01 in combination with country code value DE (Germany) results in the region Schleswig-Holstein. In comparison to that, region code value 01 in combination with country code value AR (Argentina) results in the region Buenos Aires. That means that such context information can be provided in this segment as name-value-pair for each supported parameter. The element ListAgencyID can be used for partner specific code values, which are provided in the context structure. In this case the partner namespace URI should be specified. |
The response contains the list of found code lists and log items.
In this node, all found code lists are contained including their context and code value data. If a code value is provided by a partner the element ListAgencyID is filled with the corresponding partner namespace URI data.