Contents
How to Use Technical Receiver Determination
At runtime, technical receiver determination can route calls of a consumer to the binding of a provider based on given technical identifier of the provider system.
In collaborative business processes, calls are often distributed between applications on different systems in a system landscape. For example, a sales order may need to be sent to one provider system asynchronously. The response has then later to be sent back from the original provider system to the consumer system. In this asynchronous request response pattern for the response the roles change. The provider system of the first call now becomes consumer and the consumer becomes provider. In order to send the response back to the correct partner, technical receiver determination is used in order to route the call directly. The technical identifier is then sent in the initial request by the consumer to the provider system where it is used later when sending the response in order to technically determine the correct receiver system (the initial consumer system).
Concept
The consumer application knows the technical ID representing the provider system and based on the technical ID, the call is routed to the corresponding system. In case of asynchronous request response pattern, the ID is provided by the consumer system in order to enable the provider system to send the response back to the correct consumer after the application has processed the request.
In case the consumer application knows the technical ID (e.g. via payload from initial consumer, from customizing or from user input) on instantiation of the consumer proxy with the help of service group the technical ID is passed and on this technical routing takes place. This means that the consumer proxy is instantiated against the provider system to which the technical ID is assigned and the business scenario configuration has been performed beforehand.
Concept Document of Technical and Logical Receiver Determination
Prerequisites
Technical receiver determination is only supported with the help of service groups. Service groups are only used in business scenario configuration.
The consumer application has to use the programming model of service groups in order to use technical receiver determination.
A provider system entity has to be created in the consumer system for each system acting as web service provider.
Business scenario configuration has been performed on provider and consumer system successfully.
Procedure
- Create a service group or use an existing one.
Here SRT_TEST_GROUP is used. - On the provider system, configure the requested service interface(s) for the service group with a certain profile/version.
- On the consumer system, create a provider system entity with the same profile/version. Configure the service group against the provider system.
Or use central business scenario configuration for both, provider- and consumer-side configuration. - In the consumer application the following code has to be executed:
data l_bus_appl_id type string.
data l_str_input type rfc_system_info.
data l_str_output type rfc_system_info_response.
data lr_co_srt_test_provider type ref to co_srt_test_provider.
try.
l_bus_appl_id = |005056953D5A1ED097D13725F2845EE5|.
lr_co_srt_test_provider = cl_srt_test_group_gen=>get_co_srt_test_provider( i_bus_appl_id = l_bus_appl_id ).
lr_co_srt_test_provider->rfc_system_info( exporting input = l_str_input
importing output = l_str_output ).
write:/ l_str_output-rfcsi_export-rfcsysid.
catch cx_ai_system_fault .
* implement suitable error handling here
catch cx_srt_public_config .
* implement suitable error handling here
endtry.
Result
The call of method GET_CO_SRT_TEST_PROVIDER delivers the instantiated consumer proxy if configured with the help of business scenario configuration.