Working with Service Variants

Use

Service variants provide views on service interfaces that are modeled or based on a WSDL document. Instead of using all the parameters in a service interface, a service variant allows you to use only parameters that are needed for a particular business context.

A service variant is based on a service interface and reuses the implementation of that service to create the new service. It is not necessary to create a new service implementation.

A service variant has its own WSDL and service endpoint, and is published to the Service Registry in the same way as any other standard service.

Service interfaces can often contain many parameters to support several different use cases and to enable a high degree of reuse of services. For this reason, it can sometimes be difficult to know which parameters in the service interface are relevant for their specific business purpose. By using service variants, you can simplify the way a service is consumed, for example, by hiding fields or assigning fixed values.

Procedure

Creating a Service Variant

Service variants are created in the ABAP back-end system.

  1. Start transaction SVAR.

  2. Choose New.

    The Wizard for service variants is started.

  3. Specify a name and a namespace suffix for the new service variant.

    The namespace is built by concatenating the namespace prefix and the namespace suffix. The namespace prefix cannot be changed.

  4. In the Base Service Interface box, specify the service interface on which to base the new service variant, and its namespace.

  5. Choose Continue.

  6. Specify a package and a transport request.

  7. Choose Finish.

    The new service variant is now created.

    When a service variant is first created, it has the following default field states:

    Hidden with fixed value propagation

    for all optional fields

    Hidden without fixed value propagation

    for all optional fields that reference complex types

    Visible

    for all non-optional fields and for all operations

Editing a Service Variant

You can change the following properties of a service variant:

  • Hide or unhide operations from the base service interface

  • Hide fields from the base service that are not required for the service variant

  • Set fixed values for fields

  • Define optional fields as mandatory

    You cannot define mandatory fields as optional.

To change a service variant:

  1. Start the proxy editor (transaction code SPROXY).

  2. Locate the service variant that you want to change.

    Use transaction code SE80, then choose Edit Object, and search for the service variant.

  3. Go to the External View tab.

  4. Choose Edit.

    You can now change the field states.

    Below is an overview of the field states:

    Visible

    The behavior of a Visible field is the same as in the base service interface.

    Mandatory

    Only optional fields in the base service interface can be defined as mandatory in the service variant.

    To ensure that the response XML is valid, you should set to mandatory only fields that are always filled by the base service implementation. If a field in the response structure is not filled, this may result in an invalid XML response at runtime.

    Hidden

    Hidden fields are not included in the payload.

    If mandatory fields are set to hidden, a value is required.

    If a XSD default value is assigned in the base service interface, this becomes the default field value.

    If a field is hidden in a service variant, the field is not included in the service described by the variant.

    There are two different hidden states.

    • Hidden without fixed value propagation

      This state is possible only for elements that reference a complex type in the original XSD document. The element must be optional or all subelements must also have the state Hidden without fixed value propagation.

    • Hidden with fixed value propagation

      This state is possible only for leaf elements or if all subelements or attributes are hidden or optional.

      All fixed values assigned to the field or to subelements or attributes are passd to the original service implementation at runtime, unless one of the following conditions is met:

      • The subfield is part of a table

      • There is a field which is Hidden without fixed value propagation in the chain between the Hidden with fixed value propagation super field and the subfield with a fixed value,