How to send custom infotype over SAP ALE

There is a number of infotypes in SAP which are local to some country. SAP doesn’t provide any standard solution to send these country-specific or custom infotypes over ALE, cause standard IDOC contains only international infotypes. If you develop your infotype and want to send it over ALE there are some tips and tricks to handle. Today I want to tell you how to send custom infotype or country-specific infotype over SAP ALE. It’s going to be a long tutorial with a lot of images. More than I’d like to show you what is a short and long infotype record in terms of SAP integration and IDOC structure. And, of course, ABAP source codes will be provided for your convenience. Take a cup of coffee and join me with this unique tutorial never been shared before.

Sending short infotypes over SAP ALE

A short infotype is an infotype, the size of which fits into one IDOC segment. How to check? Open SE11 transaction, find an infotype structure which is PXXXX (XXXX – infotype code), sum all length fields. One IDOC segment can store 1000 symbols. If the infotype structure is longer than 1000 symbols it’s a long infotype and we will need to split it to send over SAP ALE. Will show later how it works.

To add custom infotype to a standard HRMD_A IDOC in WE31 transaction create a new segment to include it into IDOC and send over ALE. Naming rule is Z1PXXXX, 7 symbols. It’s done for prior 4.6C compatibility, so if you work with modern systems you can use longer names. The first three letters ‘Z1P’ is a must. To save time and avoid human mistakes typing all SE11 fields into segment manually you can create a segment from a template. In menu Segment -> Create with template choose DDIC structure and type in PXXXX, where XXXX is your infotype code. When you save segment systems checks its length to comply with 1000 IDOC segment length.

In my scenario, I’ll use country-specific infotype 0293. Here is how it looks like in segment.

New IDOC segment

New IDOC segment

 

Don’t forget to release the segment in Edit menu.

Read More


SAP Change Pointers in 4 steps

Today we will talk about SAP change pointers. Change pointers are that thing, which registers all object changes, which you need to send over ALE to other SAP or non-SAP system. For example, you have changed SAP HR infotype (let’s say infotype number 0002), the system records these changes internally, creates change pointer object. Then according to your ALE settings it sends updated record immediately or based on the scheduled job. So it sends only that one 0002 infotype record, not every record, not the whole bunch of infotypes. It saves a lot of time, increases SAP performance and decreases network load. Very convenient and smart in other words. There are just four steps to configure SAP change pointers for HCM or any other SAP ECC (Enterprise Central Component) module.

You can set up change pointers very easily with these 4 steps

  1. How to activate change pointers in SAP? With transaction code BD61 SAP activates change pointers across the whole system. It’s a best practice to activate change pointers only in these systems you have and manage data (like test or quality system and a production system).
    Activate Change Pointers in bd61

    Activate Change Pointers in BD61 transaction

  2. BD50 transaction activates change pointers for specific message type (or object). For SAP HCM it would be HRMD_A.
    Activate Change Pointers for HRMD_A IDOC

    Activate Change Pointers for HRMD_A IDOC

  3. Schedule RBDMIDOC program periodically to send IDOCs (the outcome of the change pointer) over ALE integration layer. The program reads change pointers tables, creates IDOCs with changed data and pushes them to ALE layer.
    RBDMIDOC

    RBDMIDOC

  4. It’s recommended to clean change pointers tables periodically. You can do this manually in BD22 transaction or automatically with RBDCPCLR program scheduled.

If you want to track specific fields, I mean, when a specific field in infotype is changed, then in SE11 in ABAP Dictionary select needed data element, switch to ‘Further characteristics’ and tick ‘Change document’ checkbox. Now changing this field in any infotype will cause a new change pointer and data change sending through ALE. Configuring change pointers is a one step in a whole SAP ALE configuration procedure.

Don’t forget to setup the whole SAP ALE landscape to send change pointers over. You can find step-by-step SAP ALE configuration guide in my other post here: 


Data conversion in SAP ALE

Some time ago we discussed SAP ALE, what it is, how it works. Here is the link. Today I want to share with you how we can change data on-fly when we need to do some conversion during the integration process.

Usually, we need conversion in heterogeneous landscapes, where different systems presented with miscellaneous settings, types, architectures. Let’s say you want to include a new SAP ERP during company acquisition into your landscape. There will be another business unites codes or personnel numbers, which differ from your present system. Or you want to send some flag depending on your conditions in the source system. Here data conversion rules come into place.

When you do SAP ALE configuration, you usually use IDOC conversion rules. So to start with conversions, have a look at these three IMG paths. Run SALE transaction and scroll down to our menu.

Read More


How SAP ALE works

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.

Read More