CRM web services

Web Service Consumption 

The Web service consumption tool enables you to create a BOL component with a root BOL object and search objects in the business object layer. This means that if you need to retrieve data from locations other than SAP CRM using Web services, the BOL object enables you to make this data available on the UI using the same tools provided for standard CRM functionality.

For example, you might want to display the following on the CRM WebClient UI:

• Data from an internal SAP ERP system
• Data from a public Web page
• Data provided by a third-party system

Web Service consumption is limited to synchronous services (stateless). The tool currently supports read and query services.

Features

The Web service consumption tool is based on standard SAP NetWeaver functionality for consuming Web services. This includes functions for generating a proxy from a WSDL file and logical port maintenance:

• An ABAP client proxy is used in SAP NetWeaver to communicate with the Web service. It represents a typed ABAP interface and hides the technical Web service details.
• The SAP NetWeaver service runtime handles the SOAP-based communication with the Web service provider. The communication details, such as host name and port, are configured separately in logical ports.

For more information, see Generating a Consumer Proxy and Configuring a Consumer Proxy in the SAP NetWeaver Creating and Consuming a Web Service section.

To meet CRM requirements, the CRM tool enables a CRM BOL object to be generated based on the WSDL file. To do this, the Web service client proxy is wrapped by a BOL object.

The steps involved when consuming a Web Service using the BOL programming model are shown below:

The first three steps shown above are provided by the SAP NetWeaver tool, while the last two are CRM specific.

As a result of providing the Web service with an interface based on BOL for Web service consumption, it is much easier to integrate the data provided by Web services in the CRM WebClient UI, since standard tools can be used.

Mapping Between Client Proxy and BOL Model

The BOL model is derived from the Web service client proxy structure. The mapping that occurs between the client proxy and the BOL model is basically as follows:

• Query
  • Corresponds to query operation
  • Name: As specified in details screen for query operations
  • Attribute structure: Selected attributes of proxy input
• Root object
  • Corresponds to read operation
  • Name: As specified in details screen for read operations
  • Attribute structure: Selected attributes of proxy output
  • Key structure: Selected key fields (read input, output)
• Relations and dependent objects
  • Relations are determined from the output structure. The output structure is usually nested, with relations pointing to dependent objects.
  • Relation name in nested structures
    • Prefilled with <Component Prefix> + field name of output structure + Rel, for example, ADDRESSES => <Component Prefix>AddressesRel
    • Structures are represented as 1:1 relations and tables as 1:n relations.
  • Dependent object name
    • Prefilled with <Component Prefix> + field name of output structure => <Component Prefix>Addresses

BOL Object Prefixes

Multiple object names are not allowed within a component set. For example if WSCT_CS contains WSCT_1 and WSCT_2, and both have the dependent object “Address”, this causes an error when the components are used, for example, in GENIL_MODEL_BROWSER.

Name are therefore made unique by prefixing each object name (query object, root object, relations) with the prefix of the component. For example, if the prefix of the component for Web service consumption is called WS the model will contain objects such as WSQuery, WSAccount, WSAddressesRel, and so on.

In certain cases where it is not possible to make a name unique using this method due to the restricted length of an object name, numbering is used at the end. You can change these BO names subsequently in the tree view.

Request Structures (Proxy Method Input)

If a service has a nested request structure, this is converted to a flat structure by the tool, as the attribute structure for BOL query objects has to be flat (read operation/root object key structure, query operation/query object attribute structure).

Response Structures (Proxy Method Output)

Response structures might also contain nested structures. If this is the case, you can decide which attributes you need from the nested structure. The following applies for a read operation:

• By selecting a structure below a table you will generate a 1:n relation. If you deselect a structure below a table, all the attributes below it will be ignored and a relation will not be generated.
• By selecting a structure you will generate a 1:1 relation. If you deselect a structure the selected attributes below it will be shifted to the selected parent structure.

Key Structures

As BOL requires a key structure to uniquely identify objects, the attributes that are key fields have to be selected in the proxy structure (read output structure). The key fields of the root object (read operation) need to be specified in the tree view. A key field also needs to be specified in the tree view for 1:n relations (tables).

New structures are generated with these fields.

Registration of Client Proxy

After a component has been generated, the new WS GeniIL component is registered automatically in exactly the same way as other components in Customizing for Customer Relationship Management under  CRM Cross-Application Components  Generic Interaction Layer/Object Layer  Basic Settings 

A new component set named <ComponentName>_WSC is also created and contains the newly created component.

UI Building

You can use the component for UI modeling in the normal manner. For more information, see How Do I Create Components and Views? and the UI Framework and Configuration section.