When planning a migration to SAP BW/4HANA it is important to understand which objects can be automatically converted and which objects need manual correction. For the more exotic object types, this information can be difficult to find. Blogs, Q&A and even SAP documentation might not be up to date with the latest features of the SAP BW/4HANA Conversion Cockpit. In this blog, Jan van Ansem describes the conversion of SAP ABAP Function Module based datasources in the BW ‘self’ system.
What are “SAP ABAP Function Module based datasources in the BW ‘self’ system”?
The clue is in the name: A SAP ABAP Function Module based datasource (FM datasource) is a generic datasource which uses a (customer) function module for data provisioning. This method of extraction used to be common practise for SAP source systems: Many SAP standard business content data sources are of this type. Customers can easily copy the standard function module (RSAX_BIW_GET_DATA) to a Z* function module and implement their own logic.
Although it was common practise to have this type of datasources in SAP source systems (SAP ERP, CRM) it was never common practise to create this type of datasources in a SAP Business Warehouse (SAP BW) target system. A more common approach was, and still is, to use SAP BW Transformation objects, which are easily extendable with complex ABAP.
‘Not common practise’ does not mean ‘impossible’ so there are plenty of productional systems which have this type of datasource. I had the ‘good fortune’ of encountering such system for my very first SAP BW/4HANA 2.0 migration.
Why are these datasources an issue?
Simply put, these datasources no longer fit in the SAP’s simplified world of data warehousing. The number or object types is greatly reduced in BW/4HANA and this is one of the object types which is no longer supported. This would still not be an issue if the automated process to convert a BW system to BW/4HANA (BW/4HANA conversion cockpit) would replace it with something with the same functionality. Unfortunately, the BW/4HANA conversion cockpit does not do this. Or does it?
The BW/4HANA conversion cockpit and the ABAP FM Datasources on the BW ‘self’ system
There are plenty of blogs which point out that the ABAP FM Datasources on the BW ‘self’ system need to be manually replaced. Often, CDS views are suggested as a replacement. This information has been partly outdated for a while and will be completely outdated soon. Right now, these datasources can be automatically migrated to BW/4HANA 2.0 but only in an ‘In Place’ migration scenario. Please refer to note 2443863 for the full details.
This is great if you are planning to do an ‘In Place’ migration. It is not good if you are considering a different scenario. My project had decided on a Shell Conversion. We are in trouble.
Replacing the Datasources with a BW/4HANA compatible object
The default option for ABAP datasources are now based on objects called CDS views. CDS views are very different from function modules If you are planning to replace a FM datasource with a CDS view based datasource, you basically need to start development from scratch. We estimated the effort of this at 200+ days of work. Additional work of this magnitude would add considerable risk to our project. You can imagine this significantly increased the stress levels on the project.
Of course, we explored alternatives. SAP suggested the use of an ABAP ‘wrapper’ program which calls the existing function modules and fills temporary tables. This can be turned into a datasource by putting a simple CDS view on the temporary tables. Another way of reusing the function modules was by consuming them in BAdI providers. These can be included in a Composite Provider, which in turn can be the source of a transformation. Should you consider this option, be aware that this does not support a delta mechanism.
The final alternative we explored was the use of HANA Calculation Views. At first, this looked an attractive solution because as a team we had more experience with this. The downside was that again, similar to CDS views, it is not possible to reuse the function modules and all logic had to be developed from scratch.
SAP to the rescue
From the start of the project we had a constructive dialogue with SAP about the working of the conversion cockpit, specifically for ABAP FM based datasources. SAP took the feedback on board that the lack of support for automatic conversion in remote- and shell migration scenarios added a lot of risk to migration projects. This resulted in some very good news: Last Friday, SAP announced that they will extend the support for conversion of ABAP FM datasources on the SAP ‘Self’ system to the remote and shell conversion scenarios. SAP is planning to release the notes with this functionality before the end of this week (w/e Friday 13th December 2019)!
End of story?
Not quite. First of all: seeing is believing. I am relieved SAP have announced to support the conversion of ABAP FM datasources on the BW ‘Self’ system but I have not yet seen it in action. I hope I can update this blog later this week with some good news.
Secondly – SAP will not continue to support these objects. The automatic conversion does help to reduce the effort (and risk) of a BW/4HANA migration, but SAP warns that these datasources might stop working in a future version of BW/4HANA 2.0 (note 2443863).
On our project, we will move to ‘something else’, but at least we don’t have to do this at the same time as the migration to BW/4HANA. What this ‘something else’ will look like remains to be seen. This will be picked up in phase 2, post migration, when the BW/4HANA design will be optimized and aligned with current best practise.
UPDATE 16th December 2019
The migration can now be done through the conversion cockpit.
Read the step-by-step process here.