Migration of SAP ABAP FM based Datasources on the BW Self system to BW/4HANA (Part 2)

[Jan_van_Ansem]

Last week I wrote about SAP ABAP FM based datasources and SAP’s promise to automate the migration of these objects to SAP BW/4HANA (see my previous blog). This week I can share that SAP have delivered on their promise and these objects can now be migrated using the SAP BW/4HANA conversion cockpit. Here is how.

Step 1: Ensure you run the latest version of the conversion cockpit

As more and more organisations are migrating to SAP BW/4HANA, more and more issues with the conversion cockpit are ironed out and, in some cases, new functionality is added. It is important to regularly check for updates, and apply the updates as soon as they come available. Run the ‘Note Analyzer (see note 2383530) to identify new or outdated notes and take action accordingly. Specifically, note 2860021 needs to be up to date for conversion of SAP ABAP FM datasources to BW/4HANA.

Step 2: Create a BW ‘Self’ source system of type ‘ODP-SAPI’ in SAP BW/4HANA

The BW ‘Self’ connection has made a comeback. When you have the latest notes implemented (Note Analyzer, see above) you can now create a source system ‘self’ connection of type ODP-SAPI. This is the source system where the datasources will appear once they have been migrated.
(I received feedback from SAP that this will only work after you have done an initial transfer, so the receiver system 'knows' there is a ODP-SAPI context in the source).

Step 3: Import or re-created Function Module and Extract Structure

The conversion cockpit will not automatically include objects which are required for the correct working of the datasources. In RSO2 you can see which Extract Structure and Function Module is used by the datasource. These objects should be active in the target BW/4HANA system before migrating the datasource.



Of course, both objects will have further dependencies, so some further analysis is required. I ended up transporting the Extract Structures from the legacy SAP BW 7.4 system to SAP BW/4HANA but decided to re-create the function modules manually.

Of course, depending on the complexity of your Function Module, and the compatibility of your ABAP code, this might be the step where you find yourself spending the most time. There is no automated conversion for ABAP Function Modules and I don’t expect such feature will ever be introduced.

Step 4: Transport ‘Extractor’ (OSOA object) and release for ODP

This was new to me. When transporting extractors I had only ever concerned myself with objects of type ‘RSDS’. There is another object type which comes into play though. SAP explained it nicely in the instructions they sent me:

“The ODP transfer relies on the ODP already being available in the source system. This is no different for the ‘self’ source system. This means, that prior to transferring the RSDS object on top of it, the corresponding OSOA object (aka extractor) must be present in the source system of the receiver. This would be naturally so if we had a common remote source system which will be accessed by both the BW and BW/4.

However, since we are having two different source systems here (namely the BW and the BW/4 resp.), you will have to make the extractor available yourself, because this is not part of the transfer tool. This means in the sender BW system, you have to manually compose a transport request of the OSOAs <datasource names>  and the function modules needed for them to function. This transport you import into your receiver system. Thereafter it will be necessary to release the OSOA objects for access via ODP, by running report RODPS_OS_EXPOSE in the reveiver BW/4 for the two objects.”

Step 4: OPTIONAL – Make ‘New Object Name’ for source system changeable in conversion cockpit

SAP have asked to emphasise that the below should be used in exceptional cases only and going forward, when you follow the normal migration process, you should not need to do this. The protection of the Source System name is there for a reason, so don't change it unless you are absolutely sure what you are doing.

If you already have a BW ‘Self’ system in BW/4HANA of a different type (for example ODP_CDS) and you already have migrated a datasource from the source SAP BW system, then the conversion cockpit will default all datasources of the same source system to this ‘target’ source system (yeah, you might want to read this twice, it is correct ?). Moreover, you will not be able to change the new object name of the source system in the conversion cockpit.



To make the field changeable, you need to set a parameter in the RSADMIN table. You can do this by running program SAP_RSADMIN_MAINTAIN with the following parameters:

OBJECT = MYSELF_REMOTE_SPLIT

VALUE = X

Once the parameter is set, you can change the name of the source system for BW/4HANA in the conversion cockpit.

Step 5: Run the conversion cockpit

With all the prerequisites in place, you can now run the conversion cockpit as normal. Your ABAP FM based datasource will be created in BW/4HANA and all transformations will come across correctly as well.

Final considerations

Migrating the datasources is a massive milestone on our project. We had flagged these objects as a risk to our project when we started the project as it was not clear if automated migration was supported. Only very recently we had started to plan for an additional 200+ days for developers on our project to manually replace these objects. It is a great relief that we have now seen the first successful migration of ABAP FM datasources to BW/4HANA. This does not mean we can sit back and relax: We still have to go through a lot of function modules to make the ABAP code compatible with SAP BW/4HANA and there will be a lot of testing ahead of us. There is still a minor issue with the ABAP FM datasources (they are not visible in HANA Studio – at least not with the version we are on, which uses BW modeling tools 1.21.15).



As we are one of the first to use the automated migration for this type of objects I expect we might still encounter some more issues.

Once we have migrated to BW/4HANA we will have to come up with a plan to phase out these datasources altogether, as SAP will stop support for S-API datasources (see my previous blog). For now though, we are very grateful that SAP have delivered the automated migration process and we will go full steam ahead with the migration to BW/4HANA.