What is SAP ALE?
SAP ALE – Application Link Enabling – data exchange technology, developed by SAP AG. It’s a technology because it has a set of tools, protocols, formats which allow exchanging data in real-time or offline between SAP or non-SAP systems. It’s a huge layer of settings, functionality, and opportunities which we rarely use. Let’s have a look at this stack and short SAP ALE configuration guide.
SAP ALE communication stack
CPIC – Common Programming Interface for Communication – low level communication protocol. You can read further here https://www-01.ibm.com/software/network/commserver/windows/library/cpic.htm
RFC – Remote Function Call – high level communication protocol to call remote functions
tRFC (transaction RFC) / qRFC (queued RFC) / aRFC (asynchronous RFC) / sRFC (synchronous RFC) – a way to deliver messages to the receiver with confirmation
IDOC – Intermediate DOCument / BAPI (Business Application Programming Interface) – message format
EDI – Electronic Data Interchange – data exchange procedure between SAP-nonSAP systems. International standard by chance.
ALE – Application Link Enabling – data exchange procedure between SAP-SAP.
Here is what I suggest you to discuss.
The CORE of SAP integration in SAP ALE layer
RFC – Remote Function Call, is a mechanism to call functions remotely. The idea is simple and works this way. We know some functionality exists on the remote server. ‘Hey, server, I know you have this function, I know the parameters. I want you to run it on my behalf but on your side Here is my authorization. Give me the result.’ Server spins hard drives and once it makes sure I’m not a little theft, it runs the requested function with my login. Any other program can run the same function on that same server locally. A checkbox in SE37 transaction makes the difference if it could be run remotely.
RFC by itself is a protocol that SAP components and programs use to communicate to each other. SAP ALE relies on this as a technical transport for its data. The vendor offers RFC SDK free of charge to use in your own code. If you take a look at standard RFC destinations in SM59 transaction, you’ll see a lot of standard tools use RFC to work properly. SAP GUI, SAPlpd to print docs, Adobe Designer to develop PDF forms and other tools works through RFC.
Here is the idea that we can handle RFC calls to do some useful and meaningful work for us. I used such handler to connect Time processing Server with SAP. There was a communication driver which supported RFC calls. Once I needed time data to flow in SAP I called that driver, it converted my request into its internal format and sent to own SQL-based server to communicate the time devices.
So if you have any Arduino or another hardware device you can easily develop an RFC SDK based driver to connect SAP with the real world. And it’s amazing. You register that driver in SM59 and use standard ABAP, ALE Distribution Model to ‘talk to the hardware world’. This is an Internet of Things world that much popular today.. well, after bitcoins, maybe.
Assume we’ve decided what to call: either a program or a functional module. Then we need to decide how to call it: transaction, synchronously, asynchronously or in a queue).
- sRFC (synchronous RFC) – synchronous call. Make a call, the system tries to reach remote system immediately. If it’s not available, an error is returned.
- tRFC (transaction RFC) – transaction call. Make a call, the system tries to reach remote system. If it’s not available right now, the request is delayed and stored in a box called LUW (Logical Unit of Work). These boxes are picked up and collected. Once the remote system is up delivery layer transports them one by one. But there is no strict sequence who comes first or last. Only the whole LUW is guaranteed to be executed at once like a transaction. Or canceled as a transaction. You can monitor this in SM58 transaction.
- aRFC (asynchronous RFC) – improved transaction call. It communicates more to the remote. It doesn’t wait for the remote system to execute the request, while it makes a call and goes further along the code. In case of a heavy task or bad network, these calls can hold for a while.
- qRFC (queued RFC) – is advanced tRFC with that difference when LUW boxes are delivered and executed strictly in the order they were called. Like a queue. It guarantees delivery and execution on the remote side. You can monitor this in SMQ (1,2,S,R) transactions.
Why do I write this to you? I’m confident that consultants should be aware of the ‘background’, some lower level technologies to write valid functional specs. Developers not always understand what’s beneath the functional logic consultant writes in a doc.
The basic entity to send and receive data in SAP ALE
IDOC is a data structure, which can be represented as a flat file, XML, CSV, JSON or any other format. It contains three parts:
- Control record.
- Data segments.
- Document status.
SAP ALE – How does it all work?
By event or schedule, a data extraction runs. For HR it could be a change pointer or PFAL transaction. It calls functional module to create an IDOC. It doesn’t matter if it runs one record or thousands. Data segments only restricted by network and servers.
The system searches for a recipient in the BD64 transaction (data distribution model). Every IDOC has its own message type which we setup in model distribution:
sender system – receiver system – message type – filters. If conditions match IDOC is placed into a queue to be sent to the receiver. We recall that RFC works not only for SAP but any other system supporting RFC protocol. It could even send data to a cat if we have RFC compatible cat at the office.
Based on partner settings (will cover later) receiving system understands what functional module to use to do opposite conversion from IDOC to business data.
If it is a BAPI call system does the same like for IDOC – searches through distribution model where to send a call. Once the recipient is found it makes an RFC call (qRFC or sRFC). This is how FICO module parameters are verified on payroll postings.
Of course, this is the very basics.
Let’s take a scalpel.
What is IDOC made of?
IDOC – segment – field, this is an IDOC structure. An IDOC is defined with a message type (HRMD_A for HR, transaction WE81). Depending on the system version message type reference to IDOC type (transaction WE82).
IDOC type has two parts (WE30 transaction):
- Basic type. The basic type is delivered by SAP. As a rule, it already has most of the required fields to transfer data between SAP systems. If you need something else you can use a segment from another IDOC or use an extension.
- Extension. In WE31 transaction create a new segment, and in WE30 add it as an extension for basic type. All we need is to add it in WE82 transaction to HRMD_A basic type.
Have a look:
Change IDOC extension
SAP IDOC segment definition
Assign IDOC extension to IDOC message type
Don’t forget to fill this segment with data. It could be done with user-exits or BAdI (see below). Also keep in mind when you create your own segment there are two pieces of ABAP code involved: one in the sending system to pack business data into the segment and one in the receiver system to extract data from the segment. You need to develop this code on your own and to mention this new extension in WE57 with the same functional module to process incoming data.
Suppose we’ve finished with the segment. We can fill it with the data, extract data. The question is how to send it to the right recipient.
SAP Partners are big bosses who deal
To define a route, we need to learn some definitions of a partner, port and ALE distribution model. SAP ALE Configuration is all about these simple things which we set only once like a landscape and then only add data flows.
A partner is a sender or receiver (WE20). Port – way of communication (WE21). SAP ALE Distribution model is the route itself (BD64). Air flight control center is BD87.
We setup ports in WE21 transaction. Here we see some examples, like, tRFC File, XML HTTP, XML File, ABAP PI. According to naming it’s not a big deal to understand about data exchange formats. For SAP-SAP we choose tRFC and create a new port. System asks for an RFC connection (SM59) – address where to send data. If you remember from above, RFC works above the CPI-C, what means if we need to use our own driver, we need to register it in SM59 and attach through RFC connection here, in port settings. Then we’ll get tRFC port with own driver and communication underneath. If we want to go with qRFC, tick a checkbox Queue Processing is supported.
Define port in SAP ALE
Now we create partners. A partner must be in both systems: one in a receiver and one in a sending system. Open WE20 in the sending system and create LS type (logical system) partner. Data sending will perform from the system, not any specific user or object. To ensure landscape integrity SAP has developed Logical systems – unique system naming that distinguish systems within a landscape. Every system involved in integration must have its own unique logical name, even if it’s not SAP system.
Define partner in SAP ALE
Also, create a partner in the receiving system.
Define partner in SAP ALE
We’re almost done. Let’s setup a route and test it.
In BD64 create a route like on the figure below. It says we want to send HRMD_A IDOC from ER1 client 100 to ER1 client 200.
Setup distribution model in SAP ALE
If you save the model and try to distribute (Edit – Model View – Distribute), but the system throws an error, don’t panic. Model distribution is a data exchange as well and needs additional IDOC for that. Adjust your partner to the figure.
Fix error with partner profile
Distribute it and let’s go testing.
Open PFAL, fill it with the selection data. Hit ‘Run’. Looks like no errors but there is no data appeared in ER1 200. Because when we setup port we set it to build a queue without immediate sending it places our IDOC into an outbound queue. We need to push it manually or schedule a job to do that. In BD87 we can see IDOCs in the outbound queue. Select them and hit ‘Process’.
Monitor SAP ALE IDOC processing
Something wrong with incoming IDOC. It’ because of setup of APLI processing code (Inbound IDoc: Individual Processing) for the partner in the receiving system. This code works for a lot of IDOC, but not HR. For human resources IDOCs there is HRMD processing code. The code defines the internal logic how to process IDOCs in functional modules. Change APLI to HRMD and rerun processing in BD87 transaction in the receiving system. You don’t need to run PFAL again as sending was successful.
Green semaphore and we’re done. My employee was transferred.
IDOC statuses are stored in TEDS1 table.
If you need to send data every time it’s changed in the source system, then have a look at my article about SAP Change Pointers. There are just 4 steps to set them.
Don’t forget to share and repost!
Useful SAP ALE info for ABAP
Useful user-exits and BAdI
•EXIT_SAPLRHA0_001: HR-CA: ALE Outbound Processing With Receiver Enhancement
•EXIT_SAPLRHA0_002: HR-CA: Export Parameters for ALE Inbound Processing IDOC_INPUT_HRMD
•EXIT_SAPLRHA0_003: HR-CA: Import Parameters for ALE Inbound Processing IDOC_INPUT_HRMD
•EXIT_SAPLRHA0_004: HR-CA: ALE Outbound Processing: Control Record
•EXIT_SAPLRHA0_005: HR-CA: ALE Inbound Processing: Check Object
•EXIT_SAPLRHA0_006: HR-CA: ALE Outbound Processing: Check Object
•EXIT_SAPLRHAL_001: HR-CA: ALE Outbound Processing: Change IDoc
•EXIT_SAPLRHAL_002: HR-CA: ALE Inbound Processing: Change Infotype Data
•EXIT_SAPLRHAL_003: HR-CA: ALE Outbound Processing: Convert Infotype / Segment
•EXIT_SAPLRHAL_004: HR-CA: ALE Inbound Processing: Convert Segment / Infotype
BAdI: Inbound Processing for HR Master Data
HRALE00INBOUND_IDOC
Business Add-In in inbound processing for HR master data (used in the function module IDOC_INPUT_HRMD).
BAdI: Check/Additional Processing of Object in Inbound Process
The CHECK_OBJECT method of this Business Add-In enables checks to be performed on an HR object in the RH_IDOC_OBJECTS_SAVE inbound function module. The method is accessed after customer exit SAPLRHA0_005.
BAdI: Customer-Defined Inbound Processing
HRALE00SPLIT_INBOUND
SAP-internal inbound processing for HR master data:
The system determines which HR objects should be removed from standard processing because no data structures exist for them in the receiving system. Irrespective of the type of receiving system, you can further process these HR objects.
BAdI: Fine Tuning of Original System Mechanism
HRALE00ORIGSYSTEM
Business Add-In for Original System Mechanism
BAdI: Outbound Processing HR Master Data
HRALE00OUTBOUND_IDOC
Business Add-In in output processing for HR Master Data (used in the function module RH_MASTER_IDOC_DISTRIBUTE_HRMD).