Without SAP Process Orchestration or SAP PI we also have no ESR (Enterprise Service Repository) to model/design our Service Interfaces (and generate ABAP Proxies from ESR).
However, it makes a lot sense to integrate with SAP Cloud Integration (fka CPI) using ABAP Proxies.
They are much better than the 1000 character-per-line-only SAP propietary IDocs, not only because they use XML natively, but they support synchronous and asynchronous communication as well as the handling of attachments (how would you pass a PDF along with an invoice in an IDoc? As a Base64-String separated between all the segments? noo…).
ABAP Proxies can be used within 2 different runtimes:
- WS-Runtime (Web Services configured via SOA Manager)
- XI-Runtime (SOAP XI 3.0 Protocol using the local Integration Engine)
ABAP-XI-Proxies are better to interact with SAP Cloud Integration especially for asynchronous communication, because you can use the XI Adapter, which enables you to queue/buffer messages in the DataStore/JMS Queue. In addition, you can use EOIO on sender side (ABAP Client Proxy) and process the messages with the SOAP adapter (1.x) robust mode (see our guidelines here).
ABAP-WS-Proxies can be generated from WSDL files, but ABAP-XI-Proxies can be only generated from the ESR or from the MDR (Backend Metadata Repository). This is done in transaction SPROXY:
Now, in order to generate an ABAP Proxy from the Backend, you have to create a namespace using transaction SPXNGENAPPL:
Then you enter the external name (the equivalent to a Service Interface):
Then the (empty) Proxy is created and you have to fill it with content by adding the typical content of a Service Interface (as you might know from ESR):
- Operation
- Message Type
- Data Type
I have to admit that the navigation and control is not super-intuitive but it works well and you can build complex (also table-based) structures. So far for the design time. If you design a Server Proxy (Provider, Inbound), you can stop reading here.
To make it work at runtime for Client Proxies, you have to configure the Integration Engine. This is NOT required, if you are using a generic destination towards SAP Cloud Integration.
- Add a sender id using your External Name (Service Interface) in transaction SXMSIF
- Create an iFlow-specific RFC-Destination to SAP Cloud Integration (SM59)
- Make an entry in the Integration Engine Configuration to select the correct destination for your sender id (SXMB_ADM). Make sure your Integration Engine is configured as an application system (LOC).
Last, but not least: If you ever had your ABAP-system connected to an SLD and assigned a Business System name, you are good. This is stored in the table LCRT_CLNTCACHE and will be used all over again even when no SLD connection exists.
Usually you then enter SLDAPICUST and connect against the SLD of your Solution Manager where you add your system as a Business System. If this is not possible (or to bureaucratic), keep on reading:
If the table LCRT_CLNTCACHE is empty, you have to fill it yourself, e.g. by debugging the function module LCR_GET_OWN_BUSINESS_SYSTEM or by creating a small program which is filling it:
REPORT z_xi_set_business_system.
DATA: ls_cache TYPE lcrt_clntcache,
text TYPE string,
srtfd TYPE indx_srtfd,
bs_name TYPE string.
CONCATENATE sy-sysid sy-mandt INTO text.
CONCATENATE sy-sysid '_' sy-mandt INTO bs_name.
ls_cache-srtfd = text.
ls_cache-aedat = sy-datum.
ls_cache-bs_key_name = bs_name.
ls_cache-bs_caption = bs_name.
ls_cache-bs_role = 'LOC'.
MODIFY lcrt_clntcache FROM ls_cache.
IF sy-subrc IS INITIAL.
WRITE:/ 'SLD Cache updated successfully with ', bs_name.
ENDIF.
Enjoy ABAP-XI-Proxy Messaging against SAP Cloud Integration!
