Creating Service Groups 
Overview
When you consume a Web service in a consumer application (Web service client), you can create a design time entity, which represents the used service and contains information about how you can consume that service. This information is collected in a service reference. The service reference entity enables you to use the information about consumed services in a uniform way across consumer applications based on Web services and developed in different tools, such as Composite Application Framework, Web Dynpro, Visual Composer, and Guided Procedures. You can create service references only in the consumer application’s development component (DC).
When you create a service reference, the system automatically collects information about the port type of the corresponding Web service. The port type is a standard WSDL representation of the service endpoint interface with which the Web service has been exposed during the design time.
Once you import all services and create the appropriate service references, you can develop the consumer application and then either ship it to a customer or transport it from the development landscape to a production landscape. When the application is deployed in the new landscape, an administrator has to configure it. To configure an application, the administrator establishes connections from the application to all used service endpoints in the new landscape. When the administrator configures the application, he or she must ensure that it works consistently and correctly in the new landscape. It is therefore essential that all services, which are used by the consumer application and use the same application data, also run on the same provider system.
Example
An example in which Web services use the same application data is the common practice to separate read and write APIs (Web services) to manage business objects on the provider side. You can create a Web service for query and a Web service for modification, and use both services in a consumer application that manages the business objects. To ensure that the entire consumer application runs consistently and access the same business object, both services have to be executed on the same provider system.
To assist administrators in configuring the consumer applications correctly, you group the used Web services during the design time of the consumer application. To group the services, you first create an entity called Service Group, which describes the group of Web services itself and then point the service references to that Service Group.
Depending on the scenario you want to complete, proceed with one of the following approaches:
Create the Service Group locally in the DC in which the consumer application resides. The Service Group can contain service references only from the same local DC.
Create the Service Group in a shared Service group configuration DC. A service Group, which is shared in a DC can contain service references from multiple consumer application DCs.
At a later stage, administrators can configure the consumer applications by configuring the Service Groups, which they refer. Therefore if multiple consumers refer the same Service Group, administrators can configure them at one go. By configuring a Service Group, the administrators also configure all references belonging to that group.
Concept
Service References
The system collects information about the port type (service endpoint interface) and authentication of the Web service under a single entity called service reference. For each service reference, you specify the authentication level with which the consumer application consumes the respective service. You can select one of the following authentication profiles for the appropriate authentication level:
No Authentication
Choose this option if the Web service does not require authentication during invocation at runtime. If this option is set during design time, the system does not require mandatory security configuration at runtime, however an administrator may still provide such configuration. If at runtime the administrator creates and assigns a user account, its authentication mechanism overrides the authentication settings (No Authentication) provided at design time .
Technical User
Choose this option if the Web service requires authentication with a technical or service user independently of the user that invokes the consumer application. The administrator configures the concrete service user settings (user name and password or certificate) at runtime by creating and assigning a user account. In this case, all service calls from the consumer application authenticate to the service with that user assignment.
Business User
Choose this option if the Web service requires the same authentication as the authentication provided by the user that invokes the consumer application (for example Single Sign-On (SSO)). At runtime, the administrator only establishes a SSO connection between both systems. In this case, the administrator does not have to create and assign a user account at runtime.
Business or Technical User
Choose this option if you cannot determine the authentication required by the Web service. At a later stage, the administrator determines the authentication level and provides the concrete security mechanism. If the administrator creates and assigns a user account at runtime, the system takes into account the Technical User authentication. Otherwise, if the administrator only establishes a SSO connection between the systems, Business User authentication is taken into account. This is the default authentication profile set by the toolset.
More information:
Service Groups
A Service Group represents the provider from a consumer point of view. You can create one of the following Service Groups:
Classified Service Group
In this case, the Service Group contains information about the abstract designation of the provider system in term of classifications. An example of an abstract classification is the Process Component of the consumed services.
Classified Service Groups help an administrator to get an overview to what kind of provider systems, he or she has to set up connections at runtime (for example an HR system or a Financial system).
Non-Classified Service Group
In this case, the Service Group does not contain information about the abstract designation of the provider system in term of classifications.
The tools of the SAP NetWeaver Developer Studio capture information about the provider systems and group the services, which can be invoked on the same provider system in the Service Groups. The tools enable you to decouple the Service Group and the service references in different DCs. Therefore, you can enable different communication depending on the particular use case that has to be executed. The following list outlines the differences in both approaches:
The Service Group and the service references are generated in different DCs.
The toolset allows you to create a Service Group into a Service group configuration DC. At a later stage, you can create service references from multiple consumers to the same Service Group and thus group these references together. When you deploy the Service group configuration DC on the application server, you can configure the Service Group and thus configure all consumers which refer it.
More information: Creating Shared Service Groups
You can also predefine a Service group configuration DC by creating Service Groups without particular service references. At a later stage you can create consumers and generate references to the Service Groups.
More information: Creating Predefined Service Groups
The Service Group and the service references are generated in the same DC.
The toolset allows you to create a Service Group and the corresponding service references into the consumer application DC. This approach is suitable if you do not want to stick to uniform consumer requests to the provider system. Each consumer communicates with the provider system in a different way, based on the requests over its private Service Group.
More information: Creating Private Service Groups