In SAP® Data Services 3.2 some of the SAP system security standards were overlooked, allowing you to run any ABAP program in a production environment. As part of the improvements on SAP Data Services 4.x (SAP DS) this was fixed and it is now compliant with the SAP security standards. This means that for any ETL development including ABAP dataflows you will be forced to upload the ABAP code following the typical SAP system security process: upload to development (DEV), transport the changes to quality (QA) and, finally, transport the changes to production (PROD). In this article I would like to share with you some insights on how to get your new SAP DS 4.x environment ready using SAP systems.
Configuration of SAP ERP
For this process the engagement of the BASIS team is required. All the configuration process in terms of transports required, functions to be uploaded to the ERP system, user authorizations, etc. is explained in detail in the document “Supplement for SAP”, part of the SAP DS documentation. However, there is something important missing in the documentation related to the configuration of the user. The SAP ERP user for SAP DS must have one access key (key used to identify ABAP developers in the ERP system). This key is a must if you want to be able to transport the ABAP programs (ABAP dataflows) to the production environment.
Normally, the user in the ERP system for SAP DS will be created as a communication user. Which is a good option to avoid potential security concerns (and you don’t consume any license), but a communication user cannot have access key. To be able to provide the access key for the communication user you have to temporarily make this user a dialog user, then assign the access key and revert the user back to a communication user.
Configuration of SAP Data Services 4.x
Regarding configuration of SAP Data Services 4.x, most the steps are described in detail in the admin guide of SAP DS. Here I will share with you the details related to the configuration of the datastore to create the connection to SAP ERP.
Basically we must pay attention to the following parameters:
Under “SAP” make sure you assign the following properties:
ABAP execution option -> Select the option “Execute Preloaded”, this option will force SAP DS to run the ABAP programs uploaded in SAP ERP.
Under “Upload Attributes” assign the following properties:
Status -> Select the option “K - Customer Production Program”
Application -> Select the option “S - Basis”
Development Class -> The value of this option varies from one implementation to another. Must be agreed with the BASIS team
Request ID & Task ID -> Leave these options blank. They will be automatically populated by SAP DS once you perform the upload of the ABAP programs.
If possible, the recommendation is to create different SAP ERP datastore configurations, one for each available environment, typically DEV, QA & PROD.
Uploading the ABAP dataflow programs to SAP ERP
During this process we will be forced to follow the typical SAP security process to move changes to a production environment:
Upload changes to DEV -> Transport changes to QA -> Transport changes to PROD
I will explain how to upload the ABAP dataflow programs to DEV. The transports to QA and PROD must done by the BASIS team.
1. Select the configuration for DEV environment in your SAP datastore.
2. Select the ABAP dataflow(s) you want to upload to the SAP system. Right click, select the option “Generate ABAP code…”
Generate ABAP code
3. Select a local directory where the ABAP code will be saved and check the option “Upload generated programs”. The program will be generated and uploaded to the DEV environment.
Select local directory
4. The output screen will show you the result of the process and the ABAP code uploaded.
Output screen
5. In the output screen you can find the “Request ID”, this is the ID that uniquely identifies the transport in SAP system. You must share this ID with the BASIS team, with it they will be able to transport these changes to QA and/or PROD environment.
Request ID
As we saw in this article, this improvement in SAP DS 4.x is a double edged sword. On one side, the BASIS team will be happy to now have SAP DS under control (in my experience BASIS professionals were never glad when they understood how SAP DS 3.2 runs ABAP dataflows on SAP ERP). On the other side, the BI team now has a much trickier configuration of SAP DS , as well as a lengthier time-frame to develop new ETL processes including ABAP dataflows.
From my perspective, yes, the SAP DS 4.x configuration can be trickier than before, but this is the kind of exercise that will be faster with a little practice. It’s a fact that now the development of ETL processes including ABAP dataflows require the continuous engagement of the BASIS team, but this is no more than an opportunity to train our management skills.
Don’t hesitate to leave a comment if you have any questions or suggestions to improve this post.