Contents
Concept
Technical Receiver Determination (TRD) and Logical Receiver Determination (LRD) are the current concepts for receiver (provider) determination, which replaces the use of a predefined logical port in the consumer-side programming model. (Nevertheless, using logical ports is still possible.)
TRD/LRD allows the consumer application to determine the receiver (provider) of web services using some technical ID or the business context. The business context must be provided by the consumer application. The consumer application sends the business context to LRD and the configured receiver (an instantiated consumer proxy) is returned by LRD. The consumer application must not know the logical port created in the Web service configuration framework as the logical port is determined using an identifer (technical ID or business context). This decoupling allows the logical port to be replaced without disrupting any services and also enables easy change management.
Furthermore, the generated logical port for TRD/LRD can be overwritten by a fallback logical port in case the generated logical port is not configured properly by the system.
Prerequisites
Technical and Logical Receiver Determination are only used when Business Scenario Configuration is used. Therefore, you must use Service Groups.
Programming Model
Technical and Logical Receiver Determination offer an easy programming model through the generated class for each service group. The Web service consumer application is able to instantiate the consumer proxies wrapped in a service group with one method call: GET_<Consumer_Proxy>, using either:
- a technical ID (for Technical Receiver Determination), or
- a defined business context (for Logical Receiver Determination)
The business context structure is defined in the service group with the LRD Filter structure which is an ordinary Data Dictionary (DDIC) structure.
The generated class for the service group wraps the functions provided by service group handler. The service group handler uses the input (either the technical ID or business context) to determine the receiver (provider application) and returns the instantiated consumer proxy.
Business Application ID
The Business Application ID is the technical ID used for Technical Receiver Determination. In ABAP systems the Business Application ID is generated for each SAP client.
The consumer system must store the Business Application ID for each provider sytem in the Provider System entity in the corresponding Business Application.
Non-ABAP systems must provide their own IDs that are then stored in the Provider System entity.
The consumer system must store the Business Application ID for each provider sytem in the Provider System entity in the corresponding Business Application.
Non-ABAP systems must provide their own IDs that are then stored in the Provider System entity.
Service Group
A Service Group is an ABAP development object with a unique internal name. Service Groups are used to wrap one or multiple consumer proxies which are configured together because the consumer proxies are designed to be used together by a specific consumer application to fulfill a business purpose. A Service Group can call one or multiple provider applications. All provider applications must therefore be compatible with all grouped consumer proxies in the Service Group. As the consumer proxies are used against the same provider application, technical and logical routing is done on a Service Group level and not individually for each consumer proxy.
At design time, you define the LRD filter structure for the Service Group to determine whether LRD in general is possible. Furthermore, you define whether the Service Group can be configured against only one or multiple provider systems/business applications.
Once multiple provider systems/business applications are permitted in the design-time configuration, you can also specify whether only one or multiple providers are allowed to be determined at runtime. In summary, there are five valid combinations for receiver determination in service group:
- No filter, only one receiver allowed to be configured, only one receiver allowed to be determined
- No filter, multiple receivers allowed to be configured, only one receiver allowed to be determined
- LRD filter, only one receiver allowed to be configured, only one receiver allowed to be determined
- LRD filter, multiple receivers allowed to be configured, only one receiver allowed to be determined
LRD filter, multiple receivers allowed to be configured, multiple receivers allowed to be determined
For detailed explanations please see the "Service Group Characteristics" section in How To Create a Service Group.
Technical Receiver Determination
Technical Receiver Determination is used by the Web service consumer application when the application knows which receiver (Web service provider) to call, using a technical identifier. The technical identifier is the business application ID.
Example: The asynchronous request-response communication method. Here, the consumer application sends the initial Web service message to the provider and passes its own business application ID in the payload. The provider processes the message asynchronously, and later sends a response back to the consumer using TRD. In other words, the provider system uses the business application ID passed by the consumer in the request to determine the correct receiver.
Logical Receiver Determination
Logical Receiver Determination allows flexible routing of Web service calls based on business context data. The business context is defined within an LRD filter in the service group. The consumer application passes the business context via the LRD filter to the Service Group handler at runtime. The Service Group handler is wrapped by the generated class for each Service Group. In this class, a GET_<Consumer_Proxy> method exists for each consumer proxy in the service group that can be used by the application to ease the consumer side call for consumer proxy instantiation using LRD.
Based on the routing rules in the LRD filter (specified in SOA Manager), the correct receiver (provider) is determined using the business context passed by the consumer application.
Routing Rules in LRD Filter
The routing rules used for LRD are defined in SOA Manager for each service group. Routing rules specify conditions which determine the provider system business applicaton at runtime. A condition consists of one or multiple routing rows, or conditions. A condition is an ABAP range table row with the following structure: field name, sign, option, value low and value high. Conditions for the same component are combined with logical ‘AND’ operators. Conditions for different components are combined with logical ‘OR’ operators.
The filter structure defines all the components available to define rules for a business context. For one provider system/business application, multiple routing rules can be defined.
Routing rules are checked against other existing routing rules. If the system detects a potential overlap/conflict, the new routing rule is set to inactive. These can be later activated (as well as deactivated).
You can simulate the processing of routing rules. You can then check whether the routing rules determine the correct receiver (provider system) based on a given business context. You can also create documentation for the service group and routing usage.
Routing rules can be edited from a remote/central system.