Show TOC

Procedure documentationWorking with Service Variants Locate this document in the navigation structure

 

Service variants provide views on service interfaces. 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.

    Note Note

    Alternatively, you can start the Wizard from the context menu in the root node of the package. Choose   Create   Service Provider   Service Variant  

    End of the note.

  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.

    Note Note

    The service interface you specify must be released. If the service interface is not released, the system prevents you from continuing.

    End of the note.

  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 field and for all operations

    Note Note

    If the base service is changed, for example, if optional fields or operations are added, the default state for the new fields and the new operations is Hidden without fixed value propagation.

    End of the note.
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 attributes.

    Below is an overview of the field attributes:

    Visible

    Visible applies when none of the hidden states is used.

    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.

    Note Note

    This attribute cannot be used for tables (maxOccurs > 1).

    End of the note.

    Hidden

    Hidden fields are not included in the XSD document.

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

    If a XSD default value is assigned to 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 WSDL document when it is generated.

    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.

      Note Note

      This option cannot be used for tables (maxOccurs > 1).

      End of the note.

      All fixed values assigned to the field or to subelements or attributes are assigned to the ABAP variables 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,

More Information

Configuring a Service Provider